Network Working Group M. Handley
Request for Comments: 4566 UCL
Obsoletes: 2327, 3266 V. Jacobson
Category: Standards Track Packet Design
C. Perkins
University of Glasgow
July 2006
SDP: Session Description Protocol
이 문서는 인터넷 커뮤니티를 위한 인터넷 표준 추적 프로토콜을 지정하고 개선을 위한 토론 및 제안을 요청합니다. 이 프로토콜의 표준화 상태 및 상태에 대해서는 "Internet Official Protocol Standards"(STD 1) 최신판을 참조하십시오. 이 메모의 배포는 무제한입니다.
Copyright (C) The Internet Society (2006).
이 메모는 세션 설명 프로토콜(SDP)을 정의합니다. SDP는 세션 발표, 세션 초대 및 기타 형태의 멀티미디어 세션 시작을 위해 멀티미디어 세션을 설명하기 위한 것입니다.
1. Introduction ....................................................3
2. Glossary of Terms ...............................................3
3. Examples of SDP Usage ...........................................4
3.1. Session Initiation .........................................4
3.2. Streaming Media ............................................4
3.3. Email and the World Wide Web ...............................4
3.4. Multicast Session Announcement .............................4
4. Requirements and Recommendations ................................5
4.1. Media and Transport Information ............................6
4.2. Timing Information .........................................6
4.3. Private Sessions ...........................................7
4.4. Obtaining Further Information about a Session ..............7
4.5. Categorisation .............................................7
4.6. Internationalisation .......................................7
5. SDP Specification ...............................................7
5.1. Protocol Version ("v=") ...................................10
5.2. Origin ("o=") .............................................11
5.3. Session Name ("s=") .......................................12
5.4. Session Information ("i=") ................................12
5.5. URI ("u=") ................................................13
5.6. Email Address and Phone Number ("e=" and "p=") ............13
5.7. Connection Data ("c=") ....................................14
5.8. Bandwidth ("b=") ..........................................16
5.9. Timing ("t=") .............................................17
5.10. Repeat Times ("r=") ......................................18
5.11. Time Zones ("z=") ........................................19
5.12. Encryption Keys ("k=") ...................................19
5.13. Attributes ("a=") ........................................21
5.14. Media Descriptions ("m=") ................................22
6. SDP Attributes .................................................24
7. Security Considerations ........................................31
8. IANA Considerations ............................................33
8.1. The "application/sdp" Media Type ..........................33
8.2. Registration of Parameters ................................34
8.2.1. Media Types ("media") ..............................34
8.2.2. Transport Protocols ("proto") ......................34
8.2.3. Media Formats ("fmt") ..............................35
8.2.4. Attribute Names ("att-field") ......................36
8.2.5. Bandwidth Specifiers ("bwtype") ....................37
8.2.6. Network Types ("nettype") ..........................37
8.2.7. Address Types ("addrtype") .........................38
8.2.8. Registration Procedure .............................38
8.3. Encryption Key Access Methods .............................39
9. SDP Grammar ....................................................39
10. Summary of Changes from RFC 2327 ..............................44
11. Acknowledgements ..............................................45
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................46
멀티미디어 원격 회의, VoIP 통화, 스트리밍 비디오 또는 기타 세션을 시작할 때 미디어 세부 정보, 전송 주소 및 기타 세션 설명 메타데이터를 참가자에게 전달해야 한다는 요구 사항이 있습니다.
SDP는 해당 정보가 전송되는 방식에 관계없이 해당 정보에 대한 표준 표현을 제공합니다. SDP는 순전히 세션 설명을 위한 형식입니다. 전송 프로토콜을 포함하지 않으며 세션 알림 프로토콜[14], 세션 시작 프로토콜[15], 실시간 스트리밍 프로토콜을 비롯한 다양한 전송 프로토콜을 적절하게 사용하기 위한 것입니다. [16], MIME 확장자를 사용하는 전자 메일, 하이퍼텍스트 전송 프로토콜.
SDP는 광범위한 네트워크 환경과 애플리케이션에서 사용할 수 있도록 범용으로 만들어졌습니다. 그러나 이는 세션 콘텐츠 또는 미디어 인코딩 협상을 지원하기 위한 것이 아닙니다. 이는 세션 설명 범위를 벗어나는 것으로 간주됩니다.
이 메모는 RFC 2327 [6] 및 RFC 3266 [10]을 폐기합니다. 섹션 10에는 이 메모에 도입된 변경 사항이 요약되어 있습니다.
다음 용어는 이 문서에서 사용되며 이 문서의 맥락 내에서 특정 의미를 갖습니다.
회의: 멀티미디어 회의는 두 명 이상의 회의입니다.
세션: 멀티미디어 세션은 멀티미디어 발신자와 수신자, 그리고 발신자에서 수신자로 흐르는 데이터 스트림의 집합입니다. 멀티미디어 회의는 멀티미디어 세션의 한 예입니다.
세션 설명: 멀티미디어 세션을 검색하고 참여하는 데 충분한 정보를 전달하기 위해 잘 정의된 형식입니다.
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 및 "OPTIONAL"은 다음과 같습니다. RFC 2119 [3]에 설명된 대로 해석됩니다.(MUST NOT)
SIP(Session Initiation Protocol)[15]는 인터넷 멀티미디어 회의, 인터넷 전화통화, 멀티미디어 배포 등의 세션을 생성, 수정, 종료하기 위한 애플리케이션 계층 제어 프로토콜이다. 세션을 생성하는 데 사용되는 SIP 메시지에는 참가자가 호환 가능한 미디어 유형 집합에 동의할 수 있도록 하는 세션 설명이 포함되어 있습니다. 이러한 세션 설명은 일반적으로 SDP를 사용하여 형식화됩니다. SIP와 함께 사용되는 경우 제안/응답 모델[17]은 SDP를 사용한 협상을 위한 제한된 프레임워크를 제공합니다.
실시간 스트리밍 프로토콜(RTSP)[16]은 실시간 속성을 사용하여 데이터 전달을 제어하기 위한 애플리케이션 수준 프로토콜입니다. RTSP는 오디오 및 비디오와 같은 실시간 데이터의 제어된 온디맨드 전달을 가능하게 하는 확장 가능한 프레임워크를 제공합니다. RTSP 클라이언트와 서버는 미디어 전달을 위한 적절한 매개변수 세트를 협상하며 부분적으로 SDP 구문을 사용하여 해당 매개변수를 설명합니다.
세션 설명을 전달하는 대체 수단으로는 전자 메일과 WWW(World Wide Web)가 있습니다. 이메일과 WWW 배포 모두에 미디어 유형 "application/sdp"가 사용됩니다. 이를 통해 표준 방식으로 WWW 클라이언트 또는 메일 리더에서 세션에 참여하기 위한 응용 프로그램을 자동으로 시작할 수 있습니다.
이메일이나 WWW를 통해서만 이루어진 멀티캐스트 세션 공지에는 멀티캐스트 세션의 범위가 제한될 수 있고 WWW 서버에 대한 액세스 또는 이메일 수신이 제한될 수 있으므로 세션 공지의 수신자가 반드시 세션을 수신할 수 있는 속성이 없습니다. 이 범위 밖에서도 가능합니다.
멀티캐스트 멀티미디어 회의 및 기타 멀티캐스트 세션의 광고를 지원하고 관련 세션 설정 정보를 잠재 참가자에게 전달하기 위해 분산 세션 디렉토리가 사용될 수 있습니다. 이러한 세션 디렉터리의 인스턴스는 잘 알려진 멀티캐스트 그룹에 세션 설명이 포함된 패킷을 주기적으로 보냅니다. 이러한 광고는 잠재적인 원격 참가자가 세션 설명을 사용하여 세션에 참여하는 데 필요한 도구를 시작할 수 있도록 다른 세션 디렉터리에서 수신됩니다.
이러한 분산 디렉터리를 구현하는 데 사용되는 프로토콜 중 하나는 SAP(Session Announcement Protocol)입니다[14]. SDP는 이러한 세션 공지에 권장되는 세션 설명 형식을 제공합니다.
SDP의 목적은 세션 설명 수신자가 세션에 참여할 수 있도록 멀티미디어 세션에서 미디어 스트림에 대한 정보를 전달하는 것입니다. SDP는 다른 네트워크 환경에서의 회의를 설명할 수 있을 만큼 충분히 일반적이지만 기본적으로 인터네트워크에서 사용하기 위한 것입니다. 미디어 스트림은 다대다일 수 있습니다. 세션이 지속적으로 활성화될 필요는 없습니다.
지금까지 인터넷의 멀티캐스트 기반 세션은 트래픽을 수신하는 사람은 누구나 세션에 참여할 수 있다는 점에서 다른 많은 형태의 회의와 달랐습니다(세션 트래픽이 암호화되지 않은 경우). 이러한 환경에서 SDP는 두 가지 주요 목적을 수행합니다. 세션의 존재를 알리는 수단이며, 세션에 참여하고 참여할 수 있도록 충분한 정보를 전달하는 수단입니다. 유니캐스트 환경에서는 후자의 목적만 관련될 수 있습니다.
SDP 세션 설명에는 다음이 포함됩니다.
o 세션 이름 및 목적
o 세션이 활성화된 시간
o 세션을 구성하는 미디어
o 해당 미디어를 수신하는 데 필요한 정보(주소, 포트, 형식 등)
세션에 참여하는 데 필요한 리소스가 제한될 수 있으므로 몇 가지 추가 정보도 바람직할 수 있습니다.
o 세션에서 사용할 대역폭에 대한 정보
o 세션 책임자의 연락처 정보
일반적으로 SDP는 애플리케이션이 세션에 참여할 수 있도록(암호화 키 제외) 충분한 정보를 전달하고 알아야 할 비참여자에게 사용할 리소스를 알릴 수 있어야 합니다. (이 후자 기능은 SDP가 멀티캐스트 세션 알림 프로토콜과 함께 사용될 때 주로 유용합니다.)
SDP 세션 설명에는 다음 미디어 정보가 포함됩니다.
o 미디어 유형(비디오, 오디오 등)
o 전송 프로토콜(RTP/UDP/IP, H.320 등)
o 미디어 형식(H.261 비디오, MPEG 비디오 등)
미디어 형식 및 전송 프로토콜 외에도 SDP는 주소 및 포트 세부 정보를 전달합니다. IP 멀티캐스트 세션의 경우 이는 다음으로 구성됩니다.
o 미디어의 멀티캐스트 그룹 주소
o 미디어 전송 포트
이 주소와 포트는 멀티캐스트 스트림의 전송, 수신 또는 둘 다의 대상 주소와 대상 포트입니다.
유니캐스트 IP 세션의 경우 다음이 전달됩니다.
o 미디어의 원격 주소
o 미디어용 원격 전송 포트
이 주소와 포트의 의미는 정의된 미디어와 전송 프로토콜에 따라 달라집니다. 기본적으로 이는 데이터가 전송되는 원격 주소 및 원격 포트여야 합니다. 일부 미디어 유형은 이 동작을 재정의할 수 있지만 이는 구현을 복잡하게 만들기 때문에 권장되지 않습니다(NAT(네트워크 주소 변환) 또는 방화벽 핀홀을 열기 위해 주소를 구문 분석해야 하는 미들박스 포함).(SHOULD, SHOULD NOT)
세션은 시간에 제한이 있을 수도 있고 제한이 없을 수도 있습니다. 제한 여부에 관계없이 특정 시간에만 활성화될 수 있습니다. SDP는 다음을 전달할 수 있습니다.
o 세션을 제한하는 임의의 시작 및 중지 시간 목록
o For each bound, repeat times such as "every Wednesday at 10am for
one hour"
이 타이밍 정보는 현지 시간대나 일광 절약 시간에 관계없이 전 세계적으로 일관됩니다(섹션 5.9 참조).
공개 세션과 비공개 세션을 모두 생성할 수 있습니다. SDP 자체는 이들을 구별하지 않습니다. 개인 세션은 일반적으로 배포 중에 세션 설명을 암호화하여 전달됩니다. 암호화 수행 방법에 대한 세부 사항은 SDP를 전달하는 데 사용되는 메커니즘에 따라 다릅니다. 현재 SAP [14] 및 SIP [15]를 사용하여 전송되는 SDP에 대해 메커니즘이 정의되어 있으며, 향후 다른 메커니즘도 정의될 수 있습니다.
세션 알림이 비공개인 경우 해당 비공개 알림을 사용하여 각 미디어에 사용되는 암호화 체계를 알 수 있는 충분한 정보를 포함하여 회의의 각 미디어를 디코딩하는 데 필요한 암호화 키를 전달할 수 있습니다.
세션 설명은 세션 참여 여부를 결정하는 데 충분한 정보를 전달해야 합니다. SDP에는 세션에 대한 자세한 정보를 얻기 위해 URI(Uniform Resource Identifier) 형식의 추가 포인터가 포함될 수 있습니다.
많은 세션 설명이 SAP 또는 기타 광고 메커니즘에 의해 배포되는 경우 관심 있는 세션 공지와 그렇지 않은 공지를 필터링하는 것이 바람직할 수 있습니다. SDP는 자동화가 가능한 세션 분류 메커니즘을 지원합니다("a=cat:" 속성, 섹션 6 참조).
SDP 사양에서는 다양한 언어를 표현할 수 있도록 UTF-8 인코딩[5]에서 ISO 10646 문자 집합을 사용할 것을 권장합니다. 그러나 간결한 표현을 지원하기 위해 SDP는 원할 때 ISO 8859-1과 같은 다른 문자 집합을 사용할 수도 있습니다. 국제화는 자유 텍스트 필드(세션 이름 및 배경 정보)에만 적용되며 SDP 전체에는 적용되지 않습니다.
SDP 세션 설명은 미디어 유형 "application/sdp"로 표시됩니다(섹션 8 참조).
SDP 세션 설명은 UTF-8 인코딩의 ISO 10646 문자 세트를 사용하여 완전히 텍스트입니다. SDP 필드 이름과 속성 이름은 UTF-8의 US-ASCII 하위 집합만 사용하지만 텍스트 필드와 속성 값은 전체 ISO 10646 문자 집합을 사용할 수 있습니다. 필드와(MAY)
전체 UTF-8 문자 집합을 사용하는 속성 값은 직접 비교되지 않으므로 UTF-8 정규화에 대한 요구 사항이 없습니다. ASN.1 또는 XDR과 같은 이진 인코딩과 달리 텍스트 형식은 이식성을 향상시키고 다양한 전송을 사용할 수 있도록 하며 유연한 텍스트 기반 툴킷을 사용하여 생성 및 처리할 수 있도록 선택되었습니다. 세션 설명. 그러나 세션 설명의 최대 허용 크기가 제한되는 환경에서는 SDP를 사용할 수 있으므로 인코딩은 의도적으로 압축됩니다. 또한 공지 사항은 매우 신뢰할 수 없는 수단을 통해 전송되거나 중간 캐싱 서버에 의해 손상될 수 있으므로 인코딩은 엄격한 순서 및 형식 지정 규칙으로 설계되어 대부분의 오류가 쉽게 감지되고 폐기될 수 있는 잘못된 형식의 세션 공지가 발생합니다. 또한 이를 통해 수신자가 올바른 키를 갖고 있지 않은 암호화된 세션 알림을 신속하게 삭제할 수 있습니다.
SDP 세션 설명은 다음 형식의 여러 줄의 텍스트로 구성됩니다.
<type>=<value>
여기서 <type>은 정확히 하나의 대소문자 구분 문자여야 하며 <value>는 형식이 <type>에 따라 달라지는 구조화된 텍스트입니다. 일반적으로 <value>는 단일 공백 문자 또는 자유 형식 문자열로 구분된 필드 수이며, 특정 필드가 달리 정의하지 않는 한 대/소문자가 중요합니다. "=" 기호의 어느 쪽에도 공백을 사용하면 안 됩니다.(MUST, MUST NOT)
SDP 세션 설명은 세션 수준 섹션과 0개 이상의 미디어 수준 섹션으로 구성됩니다. 세션 수준 부분은 "v=" 줄로 시작하여 첫 번째 미디어 수준 섹션으로 이어집니다. 각 미디어 수준 섹션은 "m=" 줄로 시작하고 다음 미디어 수준 섹션 또는 전체 세션 설명의 끝으로 계속됩니다. 일반적으로 세션 수준 값은 동등한 미디어 수준 값으로 재정의되지 않는 한 모든 미디어의 기본값입니다.
각 설명의 일부 줄은 필수이고 일부는 선택 사항이지만 모두 여기에 제공된 순서대로 정확하게 나타나야 합니다(고정 순서는 오류 감지를 크게 향상시키고 간단한 구문 분석을 허용합니다). OPTIONAL 항목은 "*"로 표시됩니다.(MUST, MAY)
세션 설명
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
유형 문자 세트는 의도적으로 작으며 확장 가능하도록 의도되지 않았습니다. SDP 파서는 이해하지 못하는 유형 문자가 포함된 모든 세션 설명을 완전히 무시해야 합니다. 속성 메커니즘(아래 설명된 "a=")은 SDP를 확장하고 이를 특정 애플리케이션이나 미디어에 맞게 조정하는 기본 수단입니다. 일부 속성(이 메모의 섹션 6에 나열된 속성)은 정의된 의미를 갖지만 다른 속성은 애플리케이션, 미디어 또는 세션별로 추가될 수 있습니다. SDP 파서는 이해하지 못하는 모든 속성을 무시해야 합니다.(MUST, MUST)
SDP 세션 설명에는 "u=", "k=" 및 "a=" 줄의 외부 콘텐츠를 참조하는 URI가 포함될 수 있습니다. 어떤 경우에는 이러한 URI가 역참조되어 세션 설명이 자체 포함되지 않을 수 있습니다.
세션 수준 섹션의 연결("c=") 및 속성("a=") 정보는 연결 정보 또는 미디어 설명의 동일한 이름 속성으로 재정의되지 않는 한 해당 세션의 모든 미디어에 적용됩니다. 예를 들어 아래 예에서 각 미디어는 "recvonly" 속성이 지정된 것처럼 동작합니다.
SDP 설명의 예는 다음과 같습니다.
v=0
세션 이름 및 정보와 같은 텍스트 필드는 0x00(Nul), 0x0a(ASCII 개행) 및 0x0d(ASCII 캐리지 리턴)을 제외한 모든 옥텟을 포함할 수 있는 옥텟 문자열입니다. CRLF(0x0d0a) 시퀀스는 레코드를 끝내는 데 사용되지만 파서는 허용되어야 하며 단일 개행 문자로 끝나는 레코드도 허용해야 합니다. "a=charset" 속성이 없으면 이러한 옥텟 문자열은 UTF-8 인코딩의 ISO-10646 문자를 포함하는 것으로 해석되어야 합니다("a=charset" 속성이 있으면 일부 필드가 다르게 해석될 수 있습니다).(SHOULD, MUST)
세션 설명에는 "o=", "u=", "e=", "c=" 및 "a=" 줄에 도메인 이름이 포함될 수 있습니다. SDP에 사용되는 모든 도메인 이름은 [1], [2]를 준수해야 합니다. 국제화된 도메인 이름(IDN)은 [11]에 정의된 ACE(ASCII Compatible Encoding) 형식을 사용하여 표현되어야 하며 UTF-8 또는 기타 인코딩으로 직접 표현되어서는 안 됩니다. 이 요구 사항은 RFC 2327 및 기타 SDP-8과의 호환성을 위한 것입니다. 국제화된 도메인 이름 개발 이전의 관련 표준).(MUST, MUST NOT)
v=0
"v=" 필드는 세션 설명 프로토콜의 버전을 제공합니다. 이 메모는 버전 0을 정의합니다. 부 버전 번호는 없습니다.
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
"o=" 필드는 세션 작성자(사용자 이름 및 사용자 호스트 주소)와 세션 식별자 및 버전 번호를 제공합니다.
<username>은 원래 호스트의 사용자 로그인이거나, 원래 호스트가 사용자 ID 개념을 지원하지 않는 경우 "-"입니다. <username>에는 공백이 포함되어서는 안 됩니다.(MUST NOT)
<sess-id>는 <username>, <sess-id>, <nettype>, <addrtype> 및 <unicast-address>의 튜플이 세션에 대해 전역적으로 고유한 식별자를 형성하는 숫자 문자열입니다. <sess-id> 할당 방법은 생성 도구에 따라 다르지만 고유성을 보장하기 위해 NTP(Network Time Protocol) 형식의 타임스탬프를 사용하는 것이 제안되었습니다[13].
<sess-version>은 이 세션 설명의 버전 번호입니다. 세션 데이터가 수정될 때 <sess-version>이 증가하는 한 사용법은 생성 도구에 달려 있습니다. 이번에도 NTP 형식 타임스탬프를 사용하는 것이 좋습니다.(SHOULD)
<nettype>은 네트워크 유형을 제공하는 텍스트 문자열입니다. 처음에 "IN"은 "인터넷"이라는 의미를 갖는 것으로 정의되지만 나중에 다른 값이 등록될 수도 있습니다(섹션 8 참조).(MAY)
<addrtype>은 뒤에 오는 주소 유형을 제공하는 텍스트 문자열입니다. 처음에는 "IP4" 및 "IP6"이 정의되지만 나중에 다른 값이 등록될 수도 있습니다(섹션 8 참조).(MAY)
<unicast-address>는 세션이 생성된 머신의 주소입니다. IP4 주소 유형의 경우 이는 시스템의 정규화된 도메인 이름이거나 시스템의 IP 버전 4 주소를 점으로 구분한 십진수 표현입니다. IP6 주소 유형의 경우 이는 시스템의 정규화된 도메인 이름이거나 시스템의 IP 버전 6 주소에 대한 압축된 텍스트 표현입니다. IP4와 IP6 모두에 대해 정규화된 도메인 이름은 사용할 수 없는 경우를 제외하고 제공되어야 하는 형식이며, 이 경우 전역 고유 주소로 대체될 수 있습니다. 로컬 IP 주소는 SDP 설명이 주소가 의미 있는 범위를 벗어날 수 있는 모든 컨텍스트에서 사용되어서는 안 됩니다(예를 들어, 범위를 벗어날 수 있는 애플리케이션 수준 참조에 로컬 주소가 포함되어서는 안 됩니다).(SHOULD, MUST NOT)
일반적으로 "o=" 필드는 이 세션 설명 버전에 대한 전역적으로 고유한 식별자 역할을 하며, 함께 사용된 버전을 제외한 하위 필드는 수정 사항에 관계없이 세션을 식별합니다.
개인정보 보호를 위해 세션 개시자의 사용자 이름과 IP 주소를 난독화하는 것이 바람직한 경우가 있습니다. 이것이 문제가 되는 경우, 임의의 <username> 및 개인 <unicast-address>를 선택하여 "o=" 필드를 채울 수 있습니다. 단, 이러한 항목은 필드의 전역 고유성에 영향을 주지 않는 방식으로 선택해야 합니다.(MAY)
s=<session name>
"s=" 필드는 텍스트 세션 이름입니다. 세션 설명당 하나의 "s=" 필드가 있어야 합니다. "s=" 필드는 비어 있어서는 안 되며 ISO 10646 문자를 포함해야 합니다(단, "a=charset" 속성도 참조하세요). 세션에 의미 있는 이름이 없으면 "s= " 값을 사용해야 합니다(즉, 세션 이름으로 단일 공백).(MUST, MUST NOT, SHOULD)
i=<session description>
"i=" 필드는 세션에 대한 텍스트 정보를 제공합니다. 세션 설명당 최대 하나의 세션 수준 "i=" 필드가 있어야 하며, 미디어당 최대 하나의 "i=" 필드가 있어야 합니다. "a=charset" 속성이 있으면 "i=" 필드에 사용되는 문자 집합을 지정합니다. "a=charset" 속성이 없는 경우 "i=" 필드에는 UTF-8 인코딩의 ISO 10646 문자가 포함되어야 합니다.(MUST, MUST)
각 미디어 정의에 단일 "i=" 필드를 사용할 수도 있습니다. 미디어 정의에서 "i=" 필드는 주로 미디어 스트림에 레이블을 지정하기 위한 것입니다. 따라서 단일 세션에 동일한 미디어 유형의 서로 다른 미디어 스트림이 두 개 이상 있을 때 유용할 가능성이 가장 높습니다. 예를 들어 슬라이드용 화이트보드와 피드백 및 질문용 화이트보드 등 두 개의 서로 다른 화이트보드가 있습니다.(MAY)
"i=" 필드는 사람이 읽을 수 있는 자유 형식의 세션 설명이나 미디어 스트림의 목적을 제공하기 위한 것입니다. 오토마타로 구문 분석하는 데는 적합하지 않습니다.
u=<uri>
URI는 WWW 클라이언트가 사용하는 통일 자원 식별자(Uniform Resource Identifier)입니다[7]. URI는 세션에 대한 추가 정보를 가리키는 포인터여야 합니다. 이 필드는 선택 사항이지만, 존재하는 경우 첫 번째 미디어 필드 앞에 지정되어야 합니다. 세션 설명당 하나 이상의 URI 필드가 허용되지 않습니다.(MUST)
e=<email-address>
p=<phone-number>
"e=" 및 "p=" 줄은 회의 책임자의 연락처 정보를 지정합니다. 이는 반드시 회의 공지를 작성한 사람과 동일할 필요는 없습니다.
이메일 주소나 전화번호를 포함하는 것은 선택사항입니다. 이전 버전의 SDP에서는 이메일 필드나 전화 필드를 반드시 지정해야 한다고 지정했지만 이는 널리 무시되었습니다. 변경으로 인해 사양이 일반적인 사용법에 맞춰졌습니다.(MAY, MUST)
이메일 주소나 전화번호가 있는 경우 첫 번째 미디어 필드 앞에 지정해야 합니다. 세션 설명에 대해 두 개 이상의 이메일 또는 전화 필드를 제공할 수 있습니다.(MUST)
전화번호는 앞에 "+"가 붙는 국제 공중 통신 번호(ITU-T 권장 사항 E.164 참조) 형식으로 제공되어야 합니다. 원하는 경우 가독성을 높이기 위해 전화번호 필드를 분할하는 데 공백과 하이픈을 사용할 수 있습니다. 예를 들어:(SHOULD)
p=+1 617 555-6011
이메일 주소와 전화번호 모두 선택사항인 자유 텍스트 문자열을 가질 수 있으며 일반적으로 연락을 받을 수 있는 사람의 이름을 제공합니다. 존재하는 경우 반드시 괄호로 묶어야 합니다. 예를 들어:(MAY, MUST)
e=j.doe@example.com (Jane Doe)
대체 RFC 2822 [29] 이름 인용 규칙은 이메일 주소와 전화번호 모두에 허용됩니다. 예를 들어:
e=Jane Doe <j.doe@example.com>
자유 텍스트 문자열은 UTF-8 인코딩을 사용하는 ISO-10646 문자 집합이어야 하며, 적절한 세션 수준 "a=charset" 속성이 설정된 경우 ISO-8859-1 또는 다른 인코딩이어야 합니다.(SHOULD)
c=<nettype> <addrtype> <connection-address>
"c=" 필드에는 연결 데이터가 포함됩니다.
세션 설명은 각 미디어 설명에 최소한 하나의 "c=" 필드를 포함하거나 세션 수준에서 단일 "c=" 필드를 포함해야 합니다. 여기에는 단일 세션 수준 "c=" 필드와 미디어 설명당 추가 "c=" 필드가 포함될 수 있습니다. 이 경우 미디어별 값은 해당 미디어에 대한 세션 수준 설정을 재정의합니다.(MUST, MAY)
첫 번째 하위 필드("<nettype>")는 네트워크 유형을 나타내는 텍스트 문자열인 네트워크 유형입니다. 처음에 "IN"은 "인터넷"이라는 의미를 갖는 것으로 정의되지만 나중에 다른 값이 등록될 수도 있습니다(섹션 8 참조).(MAY)
두 번째 하위 필드("<addrtype>")는 주소 유형입니다. 이를 통해 IP 기반이 아닌 세션에 SDP를 사용할 수 있습니다. 이 메모는 IP4 및 IP6만 정의하지만 향후 다른 값이 등록될 수도 있습니다(섹션 8 참조).(MAY)
세 번째 하위 필드("<connection-address>")는 연결 주소입니다. <addrtype> 필드의 값에 따라 연결 주소 뒤에 선택적 하위 필드를 추가할 수 있습니다.(MAY)
<addrtype>이 IP4 및 IP6인 경우 연결 주소는 다음과 같이 정의됩니다.
o 세션이 멀티캐스트인 경우 연결 주소는 IP 멀티캐스트 그룹 주소가 됩니다. 세션이 멀티캐스트가 아닌 경우 연결 주소에는 추가 속성 필드에 의해 결정된 예상 데이터 소스, 데이터 릴레이 또는 데이터 싱크의 유니캐스트 IP 주소가 포함됩니다. 멀티캐스트 알림을 통해 전달되는 세션 설명에 유니캐스트 주소가 제공될 것으로 예상되지는 않지만 이것이 금지되는 것은 아닙니다.
o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with
which multicast packets sent in this conference will be sent. TTL
values MUST be in the range 0-255. Although the TTL MUST be
specified, its use to scope multicast traffic is deprecated;
세션의 TTL은 슬래시를 구분 기호로 사용하여 주소에 추가됩니다. 예는 다음과 같습니다:
c=IN IP4 224.2.36.42/127
IPv6 멀티캐스트는 TTL 범위 지정을 사용하지 않으므로 IPv6 멀티캐스트에 대해 TTL 값이 존재해서는 안 됩니다. 회의 범위를 제한하기 위해 IPv6 범위 주소가 사용될 것으로 예상됩니다.(MUST NOT)
계층적 또는 계층적 인코딩 체계는 단일 미디어 소스의 인코딩이 여러 레이어로 분할되는 데이터 스트림입니다. 수신기는 이러한 레이어의 하위 집합만 구독하여 원하는 품질(따라서 대역폭)을 선택할 수 있습니다. 이러한 계층화된 인코딩은 일반적으로 멀티캐스트 가지치기를 허용하기 위해 여러 멀티캐스트 그룹으로 전송됩니다. 이 기술은 특정 수준의 계층 구조만 요구하는 사이트로부터 원치 않는 트래픽을 차단합니다. 여러 멀티캐스트 그룹이 필요한 애플리케이션의 경우 연결 주소에 다음 표기법을 사용할 수 있습니다.
주소 개수가 제공되지 않으면 1개로 간주됩니다. 이렇게 할당된 멀티캐스트 주소는 기본 주소 위에 연속적으로 할당됩니다. 예를 들면 다음과 같습니다.
c=IN IP4 224.2.1.1/127/3
이는 주소 224.2.1.1, 224.2.1.2 및 224.2.1.3이 TTL 127에서 사용된다고 명시합니다. 이는 미디어 설명에 여러 개의 "c=" 줄을 포함하는 것과 의미상 동일합니다.
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127
마찬가지로 IPv6의 예는 다음과 같습니다.
c=IN IP6 FF15::101/3
이는 의미상 다음과 동일합니다.
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103
(IPv6 멀티캐스트에는 TTL 필드가 없다는 점을 기억하세요).
여러 주소 또는 "c=" 줄은 계층적 또는 계층적 인코딩 체계에서 서로 다른 계층에 대한 멀티캐스트 주소를 제공하는 경우에만 미디어별로 지정할 수 있습니다. 세션 수준 "c=" 필드에 대해 지정하면 안 됩니다.(MAY, MUST NOT)
위에 설명된 여러 주소에 대한 슬래시 표기법은 IP 유니캐스트 주소에 사용되어서는 안 됩니다.(MUST NOT)
b=<bwtype>:<bandwidth>
이 OPTIONAL 필드는 세션이나 미디어에서 사용할 제안된 대역폭을 나타냅니다. <bwtype>은 <bandwidth> 수치의 의미를 제공하는 영숫자 수정자입니다. 이 사양에는 두 가지 값이 정의되어 있지만 향후 다른 값이 등록될 수도 있습니다(섹션 8 및 [21], [25] 참조).(MAY, MAY)
CT 세션의 대역폭 또는 세션의 미디어가 범위에서 암시적인 대역폭과 다른 경우 "b=CT:..." 라인은 사용된 대역폭에 제안된 상한을 제공하는 세션에 대해 제공되어야 합니다(SHOULD). "회의 전체" 대역폭). 이것의 주요 목적은 둘 이상의 세션이 동시에 공존할 수 있는지에 대한 대략적인 아이디어를 제공하는 것입니다. RTP와 함께 CT 수정자를 사용할 때 여러 RTP 세션이 컨퍼런스의 일부인 경우 컨퍼런스 총계는 모든 RTP 세션의 총 대역폭을 나타냅니다.(SHOULD)
AS 대역폭은 특정 애플리케이션에 따라 해석됩니다(애플리케이션의 최대 대역폭 개념이 됩니다). 일반적으로 이는 적용 가능한 경우 애플리케이션의 "최대 대역폭" 제어에 설정된 것과 일치합니다. RTP 기반 애플리케이션의 경우 AS는 [19]의 섹션 6.2에 정의된 대로 RTP "세션 대역폭"을 제공합니다.
CT는 모든 사이트의 모든 미디어에 대한 총 대역폭 수치를 제공합니다. AS는 동시에 전송하는 사이트가 많더라도 단일 사이트의 단일 미디어에 대한 대역폭 수치를 제공합니다.
<bwtype> 이름에는 접두사 "X-"가 정의됩니다. 이는 실험 목적으로만 사용됩니다. 예를 들어:
b=X-YZ:128
"X-" 접두사 사용은 권장되지 않습니다. 대신 표준 네임스페이스의 IANA에 새 수정자를 등록해야 합니다. SDP 파서는 알 수 없는 수정자가 있는 대역폭 필드를 무시해야 합니다. 수정자는 영숫자여야 하며 길이 제한은 없지만 짧은 것이 좋습니다.(SHOULD NOT, MUST, MUST)
<bandwidth>는 기본적으로 초당 킬로비트로 해석됩니다. 새로운 <bwtype> 수정자의 정의는 대역폭이 일부 대체 단위로 해석되도록 지정할 수 있습니다(이 메모에 정의된 "CT" 및 "AS" 수정자는 기본 단위를 사용합니다).(MAY)
t=<start-time> <stop-time>
"t=" 행은 세션의 시작 및 중지 시간을 지정합니다. 세션이 불규칙한 간격으로 여러 번 활성화된 경우 여러 개의 "t=" 줄을 사용할 수 있습니다. 각각의 추가 "t=" 줄은 세션이 활성화되는 추가 기간을 지정합니다. 세션이 정기적으로 활성화되는 경우 "t=" 줄에 추가로 "r=" 줄(아래 참조)을 사용해야 합니다. 이 경우 "t=" 줄은 시작 및 반복 시퀀스의 정지 시간.(MAY)
첫 번째 및 두 번째 하위 필드는 각각 세션의 시작 및 중지 시간을 제공합니다. 이 값은 1900년 이후 NTP(Network Time Protocol) 시간 값(초)을 10진수로 표현한 것입니다[13]. 이 값을 UNIX 시간으로 변환하려면 십진수 2208988800을 뺍니다.
NTP 타임스탬프는 다른 곳에서 2036년에 끝나는 64비트 값으로 표시됩니다. SDP는 임의 길이의 십진수 표현을 사용하므로 문제가 발생하지 않습니다(SDP 타임스탬프는 1900년 이후 계속해서 초를 계산해야 하며 NTP는 모듈로 값을 사용합니다). 64비트 제한).(MUST)
<stop-time>이 0으로 설정되면 세션은 제한되지 않지만 <start-time> 이후까지 활성화되지 않습니다. <start-time>도 0이면 세션은 영구 세션으로 간주됩니다.
사용자 인터페이스는 세션이 실제로 종료될 시기에 대한 정보를 제공하지 않아 예약을 어렵게 만들기 때문에 제한되지 않은 영구 세션 생성을 강력히 권장하지 않아야 합니다(SHOULD).(SHOULD)
시간 초과되지 않은 제한되지 않은 세션을 사용자에게 표시할 때 제한되지 않은 세션은 현재 시간으로부터 30분까지만 활성화된다는 일반적인 가정이 이루어질 수 있습니다.
또는 세션 시작 시간 중 더 늦은 시간. 이와 다른 동작이 필요한 경우 세션이 실제로 종료되어야 하는 시기에 대한 새로운 정보가 제공되면 종료 시간이 제공되고 적절하게 수정되어야 합니다.(SHOULD)
영구 세션은 세션이 활성화되는 시기를 정확히 알려주는 연관된 반복 시간이 없으면 사용자에게 활성화되지 않는 것으로 표시될 수 있습니다.
"r=" 필드는 세션의 반복 시간을 지정합니다. 예를 들어, 세션이 월요일 오전 10시와 화요일 오전 11시에 3개월 동안 매주 한 시간 동안 활성화된 경우 해당 "t=" 필드의 <start-time>은 첫 번째 날 오전 10시의 NTP 표현입니다. 월요일이면 <반복 간격>은 1주, <활성 기간>은 1시간, 오프셋은 0과 25시간이 됩니다. 해당 "t=" 필드 중지 시간은 3개월 후 마지막 세션 종료를 나타내는 NTP 표현입니다. 기본적으로 모든 필드는 초 단위이므로 "r=" 및 "t=" 필드는 다음과 같을 수 있습니다.
t=3034423619 3042462419
r=604800 3600 0 90000
설명을 보다 간결하게 하기 위해 시간은 일, 시간 또는 분 단위로 제공될 수도 있습니다. 이에 대한 구문은 숫자 바로 뒤에 대소문자를 구분하는 단일 문자가 오는 것입니다. 분수 단위는 허용되지 않습니다. 대신 더 작은 단위를 사용해야 합니다. 다음 단위 사양 문자가 허용됩니다.
d - days (86400 seconds)
h - hours (3600 seconds)
m - minutes (60 seconds)
s - seconds (allowed for completeness)
따라서 위의 세션 발표는 다음과 같이 작성될 수도 있습니다.
r=7d 1h 0 25h
월별 및 연간 반복은 단일 SDP 반복 시간으로 직접 지정할 수 없습니다. 대신 별도의 "t=" 필드를 사용하여 세션 시간을 명시적으로 나열해야 합니다.
z=<adjustment time> <offset> <adjustment time> <offset> ....
일광 절약 시간제에서 표준 시간으로 또는 그 반대로 변경하는 동안 반복 세션을 예약하려면 기본 시간에서 오프셋을 지정해야 합니다. 이는 시간대에 따라 하루 중 다른 시간에 시간이 변경되고, 국가에 따라 날짜에 따라 일광 절약 시간이 변경되고, 일부 국가에는 일광 절약 시간이 전혀 적용되지 않기 때문에 필요합니다.
따라서 겨울과 여름이 같은 시간에 세션을 예약하려면 어느 시간대에 세션을 예약할지 명확하게 지정할 수 있어야 합니다. 수신자의 이 작업을 단순화하기 위해 발신자가 시간대 조정이 발생하는 NTP 시간과 세션이 처음 예약된 시간으로부터의 오프셋을 지정할 수 있도록 허용합니다. "z=" 필드를 사용하면 발신자는 이러한 조정 시간 목록과 기본 시간의 오프셋을 지정할 수 있습니다.
예를 들면 다음과 같습니다.
z=2882844526 -1h 2898848070 0
이는 2882844526 시간에 세션의 반복 시간이 계산되는 시간 기반이 1시간 뒤로 이동하고 2898848070 시간에 세션의 원래 시간 기반이 복원되도록 지정합니다. 조정은 항상 지정된 시작 시간을 기준으로 하며 누적되지 않습니다. 조정 내용은 세션 설명의 모든 "t=" 및 "r=" 줄에 적용됩니다.
세션이 몇 년 동안 지속될 가능성이 있는 경우, 한 번의 세션 발표로 수년간의 조정 사항을 전달하기보다는 세션 발표가 주기적으로 수정될 것으로 예상됩니다.
k=<method>
k=<method>:<encryption key>
안전하고 신뢰할 수 있는 채널을 통해 전송되는 경우 세션 설명 프로토콜을 사용하여 암호화 키를 전달할 수 있습니다. 키 교환을 위한 간단한 메커니즘은 키 필드("k=")에 의해 제공되지만 이는 주로 이전 구현과의 호환성을 위해 지원되며 그 사용은 권장되지 않습니다. SDP와 함께 사용할 새로운 키 교환 메커니즘을 정의하는 작업이 진행 중이며 [27] [28] 새로운 애플리케이션이 이러한 메커니즘을 사용할 것으로 예상됩니다.(MAY, SHOULD NOT)
키 필드는 첫 번째 미디어 항목 이전(이 경우 세션의 모든 미디어에 적용됨) 또는 필요에 따라 각 미디어 항목에 대해 허용됩니다. 키의 형식과 사용법은 이 문서의 범위를 벗어나며 키 필드는 사용할 암호화 알고리즘, 키 유형 또는 키에 대한 기타 정보를 나타낼 방법을 제공하지 않습니다. -SDP를 사용하는 레벨 프로토콜. SDP 내에서 이 정보를 전달해야 하는 경우 이전에 언급한 확장을 사용해야 합니다. 많은 보안 프로토콜에는 두 개의 키가 필요합니다. 하나는 기밀성을 위한 것이고 다른 하나는 무결성을 위한 것입니다. 이 사양은 두 개의 키 전송을 지원하지 않습니다.(SHOULD)
이 방법은 외부 수단이나 제공된 인코딩된 암호화 키로부터 사용 가능한 키를 얻는 데 사용되는 메커니즘을 나타냅니다. 다음 메소드가 정의됩니다.
k=clear:<encryption key>
k=base64:<encoded encryption key>
이 키 필드에는 암호화 키가 포함되어 있지만 SDP에서 금지된 문자가 포함되어 있어 base64로 인코딩되었습니다[12]. SDP가 보안 채널을 통해 전달된다는 것이 보장되지 않는 한 이 방법을 사용해서는 안 됩니다.(MUST NOT)
k=uri:<키를 얻기 위한 URI>
키 필드에는 URL(Uniform Resource Identifier)이 포함됩니다. URI는 키가 포함된 데이터를 참조하며 키를 반환하기 전에 추가 인증이 필요할 수 있습니다. 주어진 URI에 대한 요청이 이루어지면 응답은 키에 대한 인코딩을 지정해야 합니다. URI는 필수는 아니지만 SSL/TLS(Secure Socket Layer/Transport Layer Security)로 보호되는 HTTP URI("https:")인 경우가 많습니다.
k=prompt
이 SDP 설명에는 키가 포함되어 있지 않지만 이 키 필드가 참조하는 세션 또는 미디어 스트림은 암호화됩니다. 세션에 참여하려고 할 때 사용자에게 키를 묻는 메시지가 표시되어야 하며, 이 사용자 제공 키는 다음 작업에 사용되어야 합니다.
미디어 스트림의 암호를 해독합니다. 사용자 지정 키의 사용은 권장되지 않습니다. 이러한 키는 보안 속성이 약한 경향이 있기 때문입니다.(SHOULD NOT)
SDP가 안전하고 신뢰할 수 있는 채널을 통해 전달된다는 것이 보장되지 않는 한 키 필드를 사용해서는 안 됩니다. 이러한 채널의 예로는 S/MIME 메시지 또는 TLS로 보호되는 HTTP 세션 내에 포함된 SDP가 있습니다. 보안 채널이 중개자가 아닌 세션에 참가하도록 승인된 당사자와 함께 있는지 확인하는 것이 중요합니다. 캐싱 프록시 서버를 사용하는 경우 프록시가 신뢰할 수 있는지 또는 SDP에 액세스할 수 없는지 확인하는 것이 중요합니다. .(MUST NOT)
a=<attribute>
a=<attribute>:<value>
속성은 SDP를 확장하기 위한 기본 수단입니다. 속성은 "세션 수준" 속성, "미디어 수준" 속성 또는 둘 다로 사용되도록 정의될 수 있습니다.
미디어 설명에는 미디어에 특정한 속성("a=" 필드)이 얼마든지 있을 수 있습니다. 이를 "미디어 수준" 속성이라고 하며 미디어 스트림에 대한 정보를 추가합니다. 첫 번째 미디어 필드 앞에 속성 필드를 추가할 수도 있습니다. 이러한 "세션 수준" 속성은 개별 미디어가 아닌 컨퍼런스 전체에 적용되는 추가 정보를 전달합니다.
속성 필드는 두 가지 형식일 수 있습니다.
o 속성 속성은 단순히 "a=<flag>" 형식입니다. 이는 이진 속성이며 속성이 있으면 해당 속성이 세션의 속성임을 나타냅니다. 예를 들면 "a=recvonly"일 수 있습니다.
o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute "a=orient:
landscape"
속성 해석은 호출되는 미디어 도구에 따라 다릅니다. 따라서 세션 설명의 수신자는 일반적인 세션 설명과 특히 속성을 해석할 때 구성 가능해야 합니다.
속성 이름은 ISO-10646/UTF-8의 US-ASCII 하위 집합을 사용해야 합니다.(MUST)
속성 값은 옥텟 문자열이며 0x00(Nul), 0x0A(LF) 및 0x0D(CR)를 제외한 모든 옥텟 값을 사용할 수 있습니다. 기본적으로 속성 값은 UTF-8 인코딩을 사용하는 ISO-10646 문자 집합으로 해석됩니다. 다른 텍스트 필드와 달리 속성 값은 일반적으로 "charset" 속성의 영향을 받지 않습니다. 이렇게 하면 알려진 값과의 비교가 문제가 되기 때문입니다. 그러나 속성이 정의되면 문자 세트에 종속되도록 정의할 수 있으며, 이 경우 해당 값은 ISO-10646이 아닌 세션 문자 세트로 해석되어야 합니다.(MAY)
속성은 IANA에 등록되어야 합니다(섹션 8 참조). 이해되지 않는 속성이 수신되면 수신자는 해당 속성을 무시해야 합니다.(MUST, MUST)
m=<media> <port> <proto> <fmt> ...
세션 설명에는 여러 미디어 설명이 포함될 수 있습니다. 각 미디어 설명은 "m=" 필드로 시작하고 다음 "m=" 필드 또는 세션 설명 끝으로 종료됩니다. 미디어 필드에는 여러 하위 필드가 있습니다.
<미디어>는 미디어 유형입니다. 현재 정의된 미디어는 "오디오", "비디오", "텍스트", "응용 프로그램" 및 "메시지"이지만 이 목록은 향후 확장될 수 있습니다(섹션 8 참조).
<port>는 미디어 스트림이 전송되는 전송 포트입니다. 전송 포트의 의미는 관련 "c=" 필드에 지정된 대로 사용되는 네트워크와 미디어 필드의 <proto> 하위 필드에 정의된 전송 프로토콜에 따라 달라집니다. 미디어 응용 프로그램에서 사용하는 다른 포트(예: RTP 제어 프로토콜(RTCP) 포트[19])는 기본 미디어 포트에서 알고리즘적으로 파생되거나 별도의 속성(예: "a=rtcp:")으로 지정될 수 있습니다. [22]에 정의됨).(MAY)
연속되지 않은 포트가 사용되거나 짝수 RTP 포트와 홀수 RTCP 포트의 패리티 규칙을 따르지 않는 경우 "a=rtcp:" 속성을 사용해야 합니다. 홀수이고 "a=rtcp:"가 존재하는 <port>로 미디어를 전송하도록 요청받은 애플리케이션은 RTP 포트에서 1을 빼면 안 됩니다. 즉, <port>에 표시된 포트로 RTP를 전송해야 합니다. > "a=rtcp" 속성에 표시된 포트로 RTCP를 보냅니다.(MUST, MUST NOT)
계층적으로 인코딩된 스트림이 유니캐스트 주소로 전송되는 애플리케이션의 경우 여러 전송 포트를 지정해야 할 수도 있습니다. 이는 "c=" 필드의 IP 멀티캐스트 주소에 사용된 것과 유사한 표기법을 사용하여 수행됩니다.
m=<media> <port>/<number of ports> <proto> <fmt> ...
m=video 49170/2 RTP/AVP 31
포트 49170 및 49171이 하나의 RTP/RTCP 쌍을 형성하고 49172 및 49173이 두 번째 RTP/RTCP 쌍을 형성하도록 지정합니다. RTP/AVP는 전송 프로토콜이고 31은 형식입니다(아래 참조). 비연속 포트가 필요한 경우 별도의 속성을 사용하여 신호를 보내야 합니다(예: [22]에 정의된 "a=rtcp:").
"c=" 필드에 여러 주소가 지정되고 "m=" 필드에 여러 포트가 지정되면 포트에서 해당 주소로의 일대일 매핑이 암시됩니다. 예를 들어:
c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31
주소 224.2.1.1은 포트 49170 및 49171에 사용되고 주소 224.2.1.2는 포트 49172 및 49173에 사용됨을 의미합니다.
동일한 전송 주소를 사용하는 여러 "m=" 행의 의미는 정의되지 않습니다. 이는 제한된 과거 관행과 달리 그러한 수단으로 정의된 암시적 그룹화가 없으며 대신 의도된 의미를 표현하기 위해 명시적인 그룹화 프레임워크(예: [18])를 사용해야 함을 의미합니다.
<proto>는 전송 프로토콜입니다. 전송 프로토콜의 의미는 관련 "c=" 필드의 주소 유형 필드에 따라 달라집니다. 따라서 IP4의 "c=" 필드는 전송 프로토콜이 IP4를 통해 실행된다는 것을 나타냅니다. 다음 전송 프로토콜이 정의되어 있지만 IANA에 새로운 프로토콜을 등록하여 확장할 수 있습니다(섹션 8 참조).
* udp: UDP를 통해 실행되는 지정되지 않은 프로토콜을 나타냅니다.
* RTP/AVP: UDP를 통해 실행되는 최소 제어[20]를 사용하는 오디오 및 비디오 회의용 RTP 프로필에서 사용되는 RTP[19]를 나타냅니다.
* RTP/SAVP: UDP를 통해 실행되는 보안 실시간 전송 프로토콜[23]을 나타냅니다.
미디어 형식 외에 전송 프로토콜을 지정하는 주요 이유는 네트워크 프로토콜이 동일하더라도 동일한 표준 미디어 형식이 다른 전송 프로토콜을 통해 전달될 수 있다는 것입니다. 역사적 예는 vat PCM(펄스 코드 변조)입니다. 오디오 및 RTP PCM 오디오; 다른 하나는 TCP/RTP PCM 오디오일 수 있습니다. 또한 전송 프로토콜에 따라 다르지만 형식에 독립적인 릴레이 및 모니터링 도구도 가능합니다.
<fmt>는 미디어 형식 설명입니다. 네 번째 및 후속 하위 필드는 미디어 형식을 설명합니다. 미디어 형식의 해석은 <proto> 하위 필드의 값에 따라 달라집니다.
<proto> 하위 필드가 "RTP/AVP" 또는 "RTP/SAVP"인 경우 <fmt> 하위 필드에는 RTP 페이로드 유형 번호가 포함됩니다. 페이로드 유형 번호 목록이 제공되면 이는 이러한 모든 페이로드 형식을 세션에서 사용할 수 있지만 이러한 형식 중 첫 번째 형식을 세션의 기본 형식으로 사용해야 함을 의미합니다. 동적 페이로드 유형 할당의 경우 "a=rtpmap:" 속성(섹션 6 참조)을 사용하여 RTP 페이로드 유형 번호를 페이로드 형식을 식별하는 미디어 인코딩 이름으로 매핑해야 합니다. "a=fmtp:" 속성은 형식 매개변수를 지정하는 데 사용될 수 있습니다(섹션 6 참조).(SHOULD, SHOULD, MAY)
<proto> 하위 필드가 "udp"인 경우 <fmt> 하위 필드는 "audio", "video", "text", "application" 또는 "message" 아래의 형식을 설명하는 미디어 유형을 참조해야 합니다. 최상위 미디어 유형. 미디어 유형 등록은 UDP 전송에 사용할 패킷 형식을 정의해야 합니다.(MUST, SHOULD)
다른 전송 프로토콜을 사용하는 미디어의 경우 <fmt> 필드는 프로토콜에 따라 다릅니다. 새로운 프로토콜을 등록할 때 <fmt> 하위 필드의 해석 규칙을 정의해야 합니다(섹션 8.2.2 참조).(MUST)
다음 속성이 정의됩니다. 애플리케이션 작성자는 필요에 따라 새 속성을 추가할 수 있으므로 이 목록이 완전한 것은 아닙니다. 새로운 속성에 대한 등록 절차는 섹션 8.2.4에 정의되어 있습니다.
a=cat:<category>
a=keywds:<keywords>
cat 속성과 마찬가지로 이는 수신자에서 원하는 세션을 식별하는 데 도움이 됩니다. 이를 통해 수신자는 세션 목적을 설명하는 키워드를 기반으로 흥미로운 세션을 선택할 수 있습니다. 키워드의 중앙 레지스트리가 없습니다. 세션 수준 속성입니다. 이는 charset 종속 속성입니다. 즉, 해당 값은 세션 설명에 지정된 charset(지정된 경우) 또는 기본적으로 ISO 10646/UTF-8로 해석되어야 함을 의미합니다.
a=tool:<도구 이름 및 버전>
세션 설명을 생성하는 데 사용된 도구의 이름과 버전 번호를 제공합니다. 이는 세션 수준 속성이며 문자 세트에 종속되지 않습니다.
a=ptime:<packet time>
a=maxptime:<maximum packet time>
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
이 속성은 RTP 페이로드 유형 번호("m=" 줄에 사용됨)에서 사용할 페이로드 형식을 나타내는 인코딩 이름으로 매핑됩니다. 또한 클럭 속도 및 인코딩 매개변수에 대한 정보도 제공합니다. 문자 세트에 의존하지 않는 미디어 수준 속성입니다.
RTP 프로필이 페이로드 형식에 페이로드 유형 번호를 정적으로 할당할 수 있지만 해당 할당은 "a=rtpmap:" 속성을 사용하여 동적으로 수행되는 것이 더 일반적입니다. 정적 페이로드 유형의 예로 8kHz로 샘플링된 u-law PCM 코딩 단일 채널 오디오를 고려해 보세요. 이는 RTP 오디오/비디오 프로필에서 페이로드 유형 0으로 완전히 정의되므로 "a=rtpmap:" 속성이 필요하지 않으며 UDP 포트 49232로 전송되는 스트림에 대한 미디어는 다음과 같이 지정할 수 있습니다.
m=audio 49232 RTP/AVP 0
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
동적 페이로드 유형의 사용을 지정하는 RTP 프로필은 유효한 인코딩 이름 집합 및/또는 해당 프로필이 SDP와 함께 사용되는 경우 인코딩 이름을 등록하는 수단을 정의해야 합니다. "RTP/AVP" 및 "RTP/SAVP" 프로필은 "m=" 줄에 표시된 최상위 미디어 유형 아래에서 이름 인코딩에 미디어 하위 유형을 사용합니다. 위의 예에서 미디어 유형은 "audio/l8" 및 "audio/l16"입니다.(MUST)
오디오 스트림의 경우 <인코딩 매개변수>는 오디오 채널 수를 나타냅니다. 이 매개변수는 선택사항이며 추가 매개변수가 필요하지 않다면 채널 수가 1개인 경우 생략할 수 있습니다.(MAY)
비디오 스트림의 경우 현재 인코딩 매개변수가 지정되어 있지 않습니다.
향후 추가 인코딩 매개변수를 정의할 수 있지만 코덱별 매개변수는 추가해서는 안 됩니다. "a=rtpmap:" 속성에 추가된 매개변수는 세션 디렉터리가 적절한 미디어를 선택하는 데 필요한 매개변수여야 합니다.(SHOULD NOT, SHOULD)
세션에 참여합니다. 코덱별 매개변수는 다른 속성에 추가되어야 합니다(예: "a=fmtp:").
참고: RTP 오디오 형식에는 일반적으로 패킷당 샘플 수에 대한 정보가 포함되지 않습니다. 기본값이 아닌(RTP 오디오/비디오 프로필에 정의된 대로) 패킷화가 필요한 경우 위에 지정된 대로 "ptime" 속성이 사용됩니다.
a=recvonly
a=sendrecv
도구가 전송 및 수신 모드에서 시작되어야 함을 지정합니다. 이는 기본적으로 수신 전용 모드로 설정된 도구를 사용하는 대화형 회의에 필요합니다. 세션 또는 미디어 수준 속성일 수 있으며 문자 세트에 종속되지 않습니다.
"sendonly", "recvonly", "inactive" 및 "sendrecv" 속성 중 어느 것도 존재하지 않는 경우 "sendrecv"는 회의 유형 "broadcast" 또는 "H332"가 아닌 세션에 대한 기본값으로 가정되어야 합니다(SHOULD). (아래 참조).(SHOULD)
a=sendonly
a=inactive
도구가 비활성 모드에서 시작되어야 함을 지정합니다. 이는 사용자가 다른 사용자를 대기 상태로 만들 수 있는 대화형 회의에 필요합니다. 어떤 미디어도 전송되지 않습니다.
비활성 미디어 스트림. RTP 기반 시스템은 비활성 상태로 시작된 경우에도 여전히 RTCP를 보내야 합니다. 세션 또는 미디어 수준 속성일 수 있으며 문자 세트에 종속되지 않습니다.(SHOULD)
a=orient:<orientation>
a=type:<conference type>
컨퍼런스의 종류를 지정합니다. 제안되는 값은 "브로드캐스트", "회의", "조정", "테스트" 및 "H332"입니다. "recvonly"는 "type:broadcast" 세션의 기본값이어야 하고 "type:meeting"은 "sendrecv"를 암시해야 하며 "type:moderated"는 플로어 제어 도구의 사용과 미디어 도구가 다음과 같이 시작됨을 나타내야 합니다. 회의에 참여하는 새 사이트를 음소거합니다.
"type:H332" 속성을 지정하면 이 느슨하게 결합된 세션이 ITU H.332 사양[26]에 정의된 H.332 세션의 일부임을 나타냅니다. 미디어 도구는 "recvonly"로 시작되어야 합니다.
"type:test" 속성을 지정하는 것은 달리 명시적으로 요청하지 않는 한 수신자가 이 세션 설명을 사용자에게 표시하는 것을 안전하게 피할 수 있다는 힌트로 제안됩니다.
type 속성은 세션 수준 속성으로 charset에 종속되지 않습니다.
a=charset:<character set>
a=charset:ISO-8859-1
이것은 세션 수준 속성이며 문자 세트에 종속되지 않습니다. 지정된 문자 세트는 ISO-8859-1과 같이 IANA에 등록된 문자 세트 중 하나여야 합니다. 문자 세트 식별자는 US-ASCII 문자열이며 대소문자를 구분하지 않는 비교를 사용하여 IANA 식별자와 비교해야 합니다. 식별자가 인식되지 않거나 지원되지 않는 경우 식별자의 영향을 받는 모든 문자열은 옥텟 문자열로 간주되어야 합니다.(MUST, MUST, SHOULD)
지정된 문자 세트는 여전히 바이트 0x00(Nul), 0x0A(LF) 및 0x0d(CR)의 사용을 금지해야 합니다. 이러한 문자를 사용해야 하는 문자 집합은 해당 바이트가 텍스트 필드 내에 표시되지 않도록 하는 인용 메커니즘을 정의해야 합니다.(MUST, MUST)
a=sdplang:<language tag>
이는 세션 수준 속성이거나 미디어 수준일 수 있습니다.
기인하다. 세션 수준 속성으로 세션 설명에 대한 언어를 지정합니다. 미디어 수준 속성으로 해당 미디어와 관련된 미디어 수준 SDP 정보 필드에 대한 언어를 지정합니다. 세션 설명의 여러 언어 또는 미디어가 여러 언어를 사용하는 경우 세션 또는 미디어 수준에서 여러 sdplang 속성을 제공할 수 있습니다. 이 경우 속성의 순서는 세션의 다양한 언어 또는 가장 중요한 미디어의 중요도 순서를 나타냅니다. 가장 중요하지 않은 것.
일반적으로 여러 언어로 구성된 세션 설명을 보내는 것은 권장되지 않습니다. 대신, 세션을 설명하는 여러 설명을 각 언어별로 하나씩 전송해야 합니다. 그러나 이는 모든 전송 메커니즘에서 가능하지 않으므로 권장되지는 않지만 여러 sdplang 속성이 허용됩니다.(SHOULD, SHOULD NOT)
"sdplang" 속성 값은 US-ASCII[9]의 단일 RFC 3066 언어 태그여야 합니다. charset 속성에 종속되지 않습니다. "sdplang" 속성은 세션이 수신자의 언어를 가정할 수 없는 지리적 경계를 넘을 만큼 충분한 범위에 있거나 세션이 지역적으로 가정된 표준과 다른 언어로 되어 있는 경우 지정되어야 합니다.(SHOULD)
a=lang:<language tag>
이는 세션 수준 속성이거나 미디어 수준일 수 있습니다.
기인하다. 세션 수준 속성으로 설명되는 세션의 기본 언어를 지정합니다. 미디어 수준 속성으로 해당 미디어의 언어를 지정합니다.
지정된 세션 수준 언어를 재정의합니다. 세션 설명이나 미디어가 여러 언어를 사용하는 경우 세션이나 미디어 수준에서 여러 언어 속성을 제공할 수 있습니다. 이 경우 속성의 순서는 세션 또는 미디어에서 다양한 언어의 중요도 순서를 가장 중요한 것부터 가장 덜 중요한 것 순으로 나타냅니다. .
"lang" 속성 값은 US-ASCII [9]의 단일 RFC 3066 언어 태그여야 합니다. charset 속성에 종속되지 않습니다. "lang" 속성은 세션이 수신자의 언어를 가정할 수 없는 지리적 경계를 넘을 만큼 충분한 범위를 갖거나 세션이 지역적으로 가정된 표준과 다른 언어로 되어 있는 경우 지정되어야 합니다.(SHOULD)
a=framerate:<frame rate>
a=quality:<quality>
인코딩 품질을 정수 값으로 제안합니다. 비디오 품질 속성의 목적은 프레임 속도와 정지 이미지 품질 간의 기본이 아닌 균형을 지정하는 것입니다. 비디오의 경우 값은 0~10 범위에 있으며 다음과 같은 의미를 갖습니다.
10 - 압축 방식이 제공할 수 있는 최고의 정지 이미지 품질입니다. 5 - 품질 제안이 없는 기본 동작입니다. 0 - 코덱 설계자가 여전히 사용할 수 있다고 생각하는 최악의 정지 이미지 품질입니다.
미디어 수준 속성이며 문자셋에 종속되지 않습니다.
a=fmtp:<format> <format specific parameters>
이 속성을 사용하면 특정 형식에 특정한 매개변수를 SDP가 이해할 필요가 없는 방식으로 전달할 수 있습니다. 형식은 미디어에 지정된 형식 중 하나여야 합니다. 형식별 매개변수는 SDP에 의해 전달되고 제공되는 데 필요한 매개변수 세트일 수 있습니다.
이 형식을 사용하는 미디어 도구는 변경되지 않았습니다. 각 형식에 대해 이 속성의 인스턴스는 최대 1개만 허용됩니다.
미디어 수준 속성이며 문자셋에 종속되지 않습니다.
SDP는 유니캐스트 세션에 대한 매개변수에 동의하기 위해 제안/응답 모델[17]을 사용하는 세션 시작 프로토콜[15]과 함께 자주 사용됩니다. 이러한 방식으로 사용되는 경우 해당 프로토콜의 보안 고려 사항이 적용됩니다.
SDP는 멀티미디어 세션을 설명하는 세션 설명 형식입니다. SDP 메시지를 수신하고 그에 따라 행동하는 엔터티는 세션 설명이 알려지고 신뢰할 수 있는 소스로부터 인증된 전송 프로토콜에 의해 획득되지 않은 이상 신뢰할 수 없다는 점을 알아야 합니다. 세션 설명을 배포하기 위해 다양한 전송 프로토콜이 사용될 수 있으며 인증의 성격은 전송마다 다릅니다. 일부 전송의 경우 보안 기능이 배포되지 않는 경우가 많습니다. 세션 설명이 신뢰할 수 있는 방식으로 획득되지 않은 경우 엔드포인트는 주의를 기울여야 합니다. 왜냐하면 다른 공격 중에서 수신된 미디어 세션이 의도한 것이 아닐 수 있고, 미디어가 전송되는 대상이 예상한 것이 아닐 수 있기 때문입니다. 세션 매개변수 중 하나라도 올바르지 않거나 미디어 보안이 손상될 수 있습니다. 애플리케이션의 보안 위험과 사용자 선호도를 고려하여 합리적인 결정을 내리는 것은 엔드포인트의 몫이며 사용자에게 세션 수락 여부를 묻는 결정을 내릴 수도 있습니다.(SHOULD, SHOULD)
세션 설명을 배포하는 데 사용할 수 있는 전송 중 하나는 SAP(Session Announcement Protocol)입니다. SAP는 암호화 및 인증 메커니즘을 모두 제공하지만 세션 공지의 특성으로 인해 세션 공지의 작성자가 이전에 공지 수신자가 알려지지 않았고 공통된 내용이 없기 때문에 세션 공지의 작성자를 인증할 수 없는 경우가 많습니다. 공개 키 인프라를 사용할 수 있습니다.
인증되지 않은 전송 메커니즘을 통해 또는 신뢰할 수 없는 당사자로부터 세션 설명을 받으면 세션을 구문 분석하는 소프트웨어는 몇 가지 예방 조치를 취해야 합니다. 세션 설명에는 수신기 시스템에서 소프트웨어를 시작하는 데 필요한 정보가 포함되어 있습니다. 세션 설명을 구문 분석하는 소프트웨어는 멀티미디어 세션에 참여하기 위해 적절한 소프트웨어로 특별히 구성된 소프트웨어를 제외하고 다른 소프트웨어를 시작할 수 없어야 합니다. 일반적으로 소프트웨어가 세션을 구문 분석하는 데 부적합한 것으로 간주됩니다.(MUST NOT)
사용자 시스템에서 멀티미디어 세션에 참여하는 데 적합한 소프트웨어를 시작하기 위한 설명입니다. 단, 사용자에게 해당 소프트웨어가 시작될 것이라는 사실을 먼저 알리고 사용자의 동의를 제공하지 않은 상태입니다. 따라서 세션 발표, 이메일, 세션 초대 또는 WWW 페이지를 통해 도착하는 세션 설명은 사용자가 그러한 작업을 명시적으로 사전 승인하지 않는 한 사용자를 대화형 멀티미디어 세션으로 전달해서는 안 됩니다. 세션이 대화형인지 여부를 확인하는 것이 항상 간단한 것은 아니므로 확실하지 않은 애플리케이션은 세션이 대화형이라고 가정해야 합니다.(MUST NOT)
이 사양에는 세션 설명 수신자가 멀티미디어 도구를 기본 전송 모드로 시작하도록 알릴 수 있는 속성이 없습니다. 어떤 상황에서는 그러한 속성을 정의하는 것이 적절할 수도 있습니다. 이것이 완료되면, 그러한 속성을 포함하는 세션 설명을 분석하는 애플리케이션은 이를 무시하거나 이 세션에 참여하면 멀티미디어 데이터가 자동으로 전송된다는 점을 사용자에게 알려야 합니다. 알 수 없는 속성의 기본 동작은 이를 무시하는 것입니다.(SHOULD)
특정 환경에서는 중개 시스템이 다른 신호 프로토콜에 포함된 세션 설명을 가로채서 분석하는 것이 일반적이 되었습니다. 이는 방화벽에 구멍을 열어 미디어 스트림이 통과하도록 허용하거나 트래픽을 선택적으로 표시, 우선 순위 지정 또는 차단하는 등 다양한 목적으로 수행됩니다. 경우에 따라 이러한 중개 시스템은 세션 설명을 수정할 수 있습니다. 예를 들어 세션 설명의 내용이 동적으로 생성된 NAT 바인딩과 일치하도록 할 수 있습니다. 중개 시스템이 세션 설명의 신뢰성과 해당 통신 세션을 설정하기 위한 소스의 권한을 확립하기 위해 적절한 검사를 수행할 수 있는 방식으로 세션 설명이 전달되지 않는 한 이러한 동작은 권장되지 않습니다. SDP 자체에는 이러한 검사를 활성화하는 데 충분한 정보가 포함되어 있지 않습니다. 이는 캡슐화 프로토콜(예: SIP 또는 RTSP)에 따라 다릅니다.(SHOULD NOT)
"k=" 필드를 사용하면 세션 암호화 키를 암호화되지 않은 상태로 전달하므로 심각한 보안 위험이 발생합니다. SDP가 전달되는 채널이 비공개이고 인증된다는 것이 보장되지 않는 한 SDP는 키 자료를 전달하는 데 사용되어서는 안 됩니다. 게다가 "k=" 줄은 암호화 키 알고리즘을 표시하거나 협상하는 방법을 제공하지 않습니다. 기밀성과 무결성을 위해 별도의 키가 아닌 단일 대칭 키만 제공하므로 그 유용성이 심각하게 제한됩니다. 섹션 5.12에서 설명한 것처럼 "k=" 줄을 사용하는 것은 권장되지 않습니다.(MUST NOT, SHOULD NOT)
아래 정의된 대로 RFC 2327의 미디어 유형 등록 중 하나가 업데이트됩니다.
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
Type name: application
Subtype name: sdp
Required parameters: None.
Optional parameters: None.
인코딩 고려사항:
보안 고려사항:
Interoperability considerations:
See RFC 4566
Published specification:
See RFC 4566
이 미디어 유형을 사용하는 애플리케이션:
Additional information:
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp "
Intended usage: COMMON
작성자/변경 컨트롤러:
IANA에 등록할 수 있는 필드 이름은 7개입니다. SDP 사양 BNF(Backus-Naur Form)의 용어를 사용하면 "media", "proto", "fmt", "att-field", "bwtype", "nettype" 및 "addrtype"입니다.
미디어 유형 세트는 소규모로 설계되었으며 드문 경우를 제외하고는 확장되어서는 안 됩니다. 최상위 미디어 콘텐츠 유형과 동일한 규칙이 미디어 이름에 적용되어야 하며, 가능한 경우 MIME과 마찬가지로 SDP에도 동일한 이름이 등록되어야 합니다. 기존 최상위 미디어 콘텐츠 유형 이외의 미디어의 경우 등록할 새로운 최상위 콘텐츠 유형에 대해 표준 트랙 RFC를 생성해야 하며, 등록은 기존 미디어 이름이 적절하지 않은 이유에 대한 정당한 근거를 제공해야 합니다("표준 조치"). " RFC 2434 [8]의 정책.(SHOULD NOT, MUST)
이 메모에는 "오디오", "비디오", "텍스트", "애플리케이션", "메시지" 미디어 유형이 등록되어 있습니다.
참고: 미디어 유형 "control"과 "data"는 이 사양 [6]의 이전 버전에서 유효한 것으로 나열되었습니다. 그러나 그 의미는 완전히 지정되지 않았으며 널리 사용되지도 않습니다. RFC 3840 [24]에 정의된 대로 SIP 사용자 에이전트에 대한 유효한 미디어 유형 기능은 여전히 남아 있지만 이러한 미디어 유형은 이 사양에서 제거되었습니다. 이러한 미디어 유형이 미래에 유용하다고 간주되면 표준 트랙 RFC를 생성하여 해당 사용을 문서화해야 합니다. 그것이 완료될 때까지 애플리케이션은 이러한 유형을 사용해서는 안 되며 SIP 기능 선언에서 해당 유형에 대한 지원을 선언해서는 안 됩니다(RFC 3840에 의해 생성된 레지스트리에 존재하더라도).(MUST, SHOULD NOT)
"proto" 필드는 사용된 전송 프로토콜을 설명합니다. 이는 표준 추적 프로토콜 RFC를 참조해야 합니다(SHOULD). 이 메모는 세 가지 값을 등록합니다. "RTP/AVP"는 최소한의 제어를 사용하는 오디오 및 비디오 회의용 RTP 프로필[20]에서 사용되는 RTP[19]에 대한 참조입니다.(SHOULD)
UDP/IP를 통해 실행되는 경우 "RTP/SAVP"는 Secure Real-time Transport Protocol[23]에 대한 참조이고 "udp"는 UDP를 통한 지정되지 않은 프로토콜을 나타냅니다.
나중에 다른 RTP 프로필이 정의되면 해당 "proto" 이름을 동일한 방식으로 지정해야 합니다. 예를 들어 짧은 이름이 "XYZ"인 RTP 프로필은 "RTP/XYZ"의 "proto" 필드로 표시됩니다.(SHOULD)
새로운 전송 프로토콜은 IANA에 등록되어야 합니다. 등록은 프로토콜을 설명하는 RFC를 참조해야 합니다. 이러한 RFC는 실험적이거나 정보용일 수 있지만 표준 트랙인 것이 바람직합니다. 등록은 또한 "fmt" 네임스페이스가 관리되는 규칙을 정의해야 합니다(아래 참조).(SHOULD, MUST, MAY, MUST)
"proto" 필드에 의해 정의된 각 전송 프로토콜에는 해당 프로토콜에 의해 전달될 수 있는 미디어 형식을 설명하는 연관된 "fmt" 네임스페이스가 있습니다. 형식은 멀티미디어 세션에서 전송될 수 있는 모든 인코딩을 포함합니다.
"RTP/AVP" 및 "RTP/SAVP" 프로필 아래의 RTP 페이로드 형식은 페이로드 유형 번호를 "fmt" 값으로 사용해야 합니다. 페이로드 유형 번호가 이 세션 설명에 의해 동적으로 할당되는 경우 페이로드 형식에 대한 미디어 유형 등록에 의해 정의된 대로 형식 이름과 매개변수를 지정하기 위해 추가 "rtpmap" 속성이 포함되어야 합니다. SDP 전송 프로토콜로 등록된(RTP와 함께) 다른 RTP 프로필은 "fmt" 네임스페이스에 대해 동일한 규칙을 지정하는 것이 좋습니다.(MUST, MUST, SHOULD)
"udp" 프로토콜의 경우 새 형식을 등록해야 합니다. 해당 형식에 기존 미디어 하위 유형을 사용하는 것이 권장됩니다. 미디어 하위 유형이 없으면 해당 형식에 대한 전송 프로토콜을 정의하는 표준 트랙 RFC를 생성하거나 참조하여 IETF 프로세스[31]를 통해 적합한 하위 유형을 등록하는 것이 좋습니다.(SHOULD, SHOULD)
다른 프로토콜의 경우 관련 "proto" 사양의 규칙에 따라 형식을 등록할 수 있습니다.(MAY)
새로운 형식을 등록하려면 적용할 전송 프로토콜을 지정해야 합니다.(MUST)
속성 필드 이름("att-field")은 동일한 이름의 속성 충돌로 인해 눈에 띄는 문제가 있으므로 IANA에 등록하고 문서화해야 합니다. SDP의 알 수 없는 속성은 무시되지만 프로토콜을 조각화하는 충돌하는 속성은 심각한 문제입니다.(MUST)
사양에 다음 정보가 포함되어 있는 경우 RFC 2434의 "사양 필수" 정책에 따라 새로운 속성 등록이 허용됩니다.
o 연락처 이름, 이메일 주소, 전화번호
o attribute name (as it will appear in SDP)
o 영어로 된 긴 형식의 속성 이름
o type of attribute (session level, media level, or both)
o 속성 값이 charset 속성의 적용을 받는지 여부
o 속성의 목적에 대한 한 문단 설명
o 이 속성에 대한 적절한 속성 값의 사양
위의 내용은 IANA가 허용하는 최소 금액입니다. 광범위한 사용과 상호 운용성이 예상되는 속성은 속성을 보다 정확하게 지정하는 표준 추적 RFC로 문서화해야 합니다.(SHOULD)
등록 제출자는 사양이 SDP 속성의 정신에 부합하는지 확인해야 합니다. 특히 속성은 운영 체제에 대해 암묵적인 가정을 하지 않고 소프트웨어의 특정 부분을 방해할 수 있는 방식으로 이름을 지정하지 않는다는 점에서 플랫폼 독립적이라는 점을 보장해야 합니다. 상호 운용성.
IANA는 이 메모의 섹션 6에 정의된 다음과 같은 초기 속성 이름 세트("att-field" 값)를 등록했습니다(이러한 정의는 RFC 2327의 정의를 업데이트함).
Name | Session or Media level? | Dependent on charset?
----------+-------------------------+----------------------
cat | Session | No
keywds | Session | Yes
tool | Session | No
ptime | Media | No
maxptime | Media | No
rtpmap | Media | No
recvonly | Either | No
sendrecv | Either | No
sendonly | Either | No
inactive | Either | No
orient | Media | No
type | Session | No
charset | Session | No
sdplang | Either | No
lang | Either | No
framerate | Media | No
quality | Media | No
fmtp | Media | No
대역폭 지정자의 확산은 강력히 권장되지 않습니다.
새로운 대역폭 지정자("bwtype" 필드)는 IANA에 등록되어야 합니다. 제출물은 대역폭 지정자의 의미를 정확하게 지정하고, 사용해야 하는 시기와 기존 등록된 대역폭 지정자로 충분하지 않은 이유를 나타내는 표준 트랙 RFC를 참조해야 합니다.(MUST, MUST)
IANA는 이 메모의 섹션 5.8에 정의된 대역폭 지정자 "CT" 및 "AS"를 등록했습니다(이러한 정의는 RFC 2327의 정의를 업데이트함).
인터넷이 아닌 환경에서 SDP를 사용해야 하는 경우 새로운 네트워크 유형("nettype" 필드)이 IANA에 등록될 수 있습니다. 이는 일반적으로 IANA의 영역은 아니지만 인터넷 전화 통화를 PSTN(공중 교환 전화망)으로 게이트웨이하는 경우와 같이 인터넷 응용 프로그램이 인터넷이 아닌 응용 프로그램과 상호 운용되어야 하는 상황이 있을 수 있습니다. 네트워크 유형의 수는 작아야 하며 거의 확장되지 않아야 합니다. 해당 네트워크에 사용할 주소 유형을 하나 이상 등록하지 않으면 새 네트워크 유형을 등록할 수 없습니다.
유형. 새로운 네트워크 유형 등록은 네트워크 유형 및 주소 유형에 대한 세부 정보를 제공하고 사용 방법과 시기를 지정하는 RFC를 참조해야 합니다.(MUST)
IANA는 이 메모의 섹션 5.2 및 5.7에 정의된 대로 인터넷을 나타내기 위해 네트워크 유형 "IN"을 등록했습니다(이러한 정의는 RFC 2327의 정의를 업데이트함).
새로운 주소 유형("addrtype")이 IANA에 등록될 수 있습니다. 주소 유형은 네트워크 유형의 맥락에서만 의미가 있으며 모든 주소 유형 등록은 등록된 네트워크 유형을 지정하거나 네트워크 유형 등록과 함께 제출되어야 합니다. 새로운 주소 유형 등록은 주소 유형 구문의 세부정보를 제공하는 RFC를 참조해야 합니다. 주소 유형은 자주 등록되지 않을 것으로 예상됩니다.(MUST, MUST)
IANA는 이 메모의 섹션 5.2 및 5.7에 정의된 주소 유형 "IP4" 및 "IP6"을 등록했습니다(이러한 정의는 RFC 2327의 정의를 업데이트함).
SDP "media", "proto", "fmt", "bwtype", "nettype" 및 "addrtype" 필드를 등록하는 RFC 문서에서 작성자는 IANA가 적절한 레지스트리에 배치할 수 있도록 다음 정보를 포함해야 합니다.(MUST)
o 연락처 이름, 이메일 주소, 전화번호
o name being registered (as it will appear in SDP)
o 영어로 된 긴 이름
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype")
o 등록된 이름의 목적에 대한 한 문단 설명
o a reference to the specification for the registered name (this
will typically be an RFC number)
IANA는 검토를 위해 모든 등록을 IESG에 회부할 수 있으며, 등록이 이루어지기 전에 수정이 이루어지도록 요청할 수 있습니다.
IANA는 이전에 SDP 암호화 키 액세스 방법("enckey") 이름 테이블을 유지 관리했습니다. "k=" 줄은 확장할 수 없으므로 이 테이블은 더 이상 사용되지 않습니다. 신규 등록은 허용되어서는 안 됩니다.(MUST NOT)
이 섹션에서는 SDP에 대한 증강 BNF 문법을 제공합니다. ABNF는 [4]에 정의되어 있습니다.
; SDP Syntax
session-description = proto-version
origin-field
session-name-field
information-field
uri-field
email-fields
phone-fields
connection-field
bandwidth-fields
time-fields
key-field
attribute-fields
media-descriptions
proto-version = %x76 "=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %x73 "=" text CRLF
information-field = [%x69 "=" text CRLF]
uri-field = [%x75 "=" uri CRLF]
email-fields = *(%x65 "=" email-address CRLF)
phone-fields = *(%x70 "=" phone-number CRLF)
연결 필드 = [%x63 "=" nettype SP addrtype SP
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
time-fields = 1*( %x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
key-field = [%x6b "=" key-type CRLF]
attribute-fields = *(%x61 "=" attribute CRLF)
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
; 'o=' 사용자 이름 = ws-string이 아닌 하위 규칙; 꽤 넓은 정의이지만 공백을 포함하지 않습니다.
세션 ID = 1*DIGIT
sess-version = 1*DIGIT
nettype = token
;typically "IN"
addrtype = token
;typically "IP4" or "IP6"
; 'u='의 하위 규칙 uri = URI 참조 ; RFC 3986 참조
; sub-rules of 'e=', see RFC 2822 for definitions
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; 'p=' 전화번호의 하위 규칙 = 전화 *SP "(" 1*email-safe ")" / 1*email-safe "<" 전화 ">" / 전화
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; 'c=' 연결 주소의 하위 규칙 = 멀티캐스트 주소 / 유니캐스트 주소
; 'b='의 하위 규칙 bwtype = 토큰
bandwidth = 1*DIGIT
; sub-rules of 't='
start-time = time / "0"
stop-time = time / "0"
시간 = POS-DIGIT 9*DIGIT
; 'r=' 및 'z='의 하위 규칙 반복 간격 = POS-DIGIT *DIGIT [고정 길이-시간 단위]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %x64 / %x68 / %x6d / %x73
; sub-rules of 'k='
key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt"
%x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
%x62 %x61 %x73 %x65 "64:" base64 / ; "base64:"
%x75 %x72 %x69 ":" uri ; "uri:"
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; 'a=' 속성의 하위 규칙 = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", or
;"application"
fmt = 토큰
proto = token *("/" token)
;typically "RTP/AVP" or "udp"
port = 1*DIGIT
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
IP4-멀티캐스트 = m1 3( "." 십진수-uchar )
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
IP6-멀티캐스트 = hexpart [ "/" 정수 ]
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
IP4-address = b1 3("." decimal-uchar)
b1 = decimal-uchar
; less than "224"
; 다음은 RFC 2373 [30], 부록 B와 일치합니다. IP6-address = hexpart [ ":" IP4-address ]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
; 다른 주소 계열에 대한 일반 extn-addr = non-ws-string
; 일반 하위 규칙: 데이터 유형 텍스트 = 바이트 문자열; 기본값은 이를 UTF8 텍스트로 해석하는 것입니다. ;ISO 8859-1에서는 "a=charset:ISO-8859-1"이 필요합니다. ;세션 수준 속성을 사용해야 합니다.
바이트 문자열 = 1*(%x01-09/%x0B-0C/%x0E-FF)
비-ws-문자열 = 1*(VCHAR/%x80-FF)
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;NUL, CR, LF 또는 인용 ;문자()<>를 제외한 모든 바이트
integer = POS-DIGIT *DIGIT
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; 외부 참조:
메모는 사용 측면에서 사양에 대한 많은 설명을 포함하여 크게 재구성되었습니다. 아래에 명시된 항목을 제외하고 메모의 변경 사항은 이전 버전과 호환되는 설명을 위한 것입니다. 그러나 RFC 2327의 불일치와 불명확한 정의로 인해 일부 구현에서는 이 SDP 버전과 다른 방식으로 해당 메모를 해석했을 가능성이 있습니다.
섹션 9의 ABNF 문법은 여러 가지 실수를 수정하고 RFC 3266 IPv6 확장을 통합하여 광범위하게 개정 및 업데이트되었습니다. 문법과 사양 텍스트 간의 알려진 불일치가 해결되었습니다.
SDP에 대한 미디어 유형 등록이 포함되어 있습니다. IANA에 속성 및 기타 매개변수를 등록하기 위한 요구 사항이 명확해지고 강화되었습니다(8항). "텍스트"와 "메시지"는 SDP와 함께 사용할 수 있는 유효한 미디어 유형이지만 "제어"와 "데이터"는 제대로 지정되지 않았으며 더 이상 사용되지 않습니다.
RFC 2119 용어는 이제 요구 사항 수준을 지정하기 위해 전체적으로 사용됩니다. 특히 매개변수 등록과 관련된 특정 요구사항은 RFC 2327의 요구사항보다 더 엄격합니다.
"RTP/SAVP" RTP 프로필과 해당 "fmt" 네임스페이스가 등록됩니다.
"a=inactive" 및 "a=maxptime" 속성이 추가되었습니다.
RFC 2327에서는 "e=" 또는 "p="가 필요하도록 규정했습니다. 실제 사용량을 반영하기 위해 둘 다 이제 선택 사항입니다.
"k=" 필드의 중요한 제한 사항이 명시되어 있으며 해당 필드의 사용은 더 이상 사용되지 않습니다.
실험 매개변수에 대한 "x-" 접두사 표기법의 대부분의 사용은 허용되지 않으며 다른 사용은 더 이상 사용되지 않습니다.
IETF MMUSIC(다자간 멀티미디어 세션 제어) 작업 그룹의 많은 사람들이 이 문서에 대한 의견과 제안을 제공했습니다. 특히 Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan Rosenberg, 존 엘웰, 플레밍 안드레아슨, 존 피터슨, 스펜서 도킨스.
[1] Mockapetris, P., "도메인 이름 - 개념 및 기능", STD 13, RFC 1034, 1987년 11월.
[2] Mockapetris, P., "도메인 이름 - 구현 및
[3] Bradner, S., "요구 사항 수준을 나타 내기 위해 RFC에 사용되는 핵심 단어", BCP 14, RFC 2119, 1997년 3월.
[4] 크로커, D., 에드. 및 P. Overell, "구문 사양을 위한 보강된 BNF: ABNF", RFC 4234, 2005년 10월.
[5] Yergeau, F., "UTF-8, ISO 10646의 변환 형식", STD 63, RFC 3629, 2003년 11월.
[6] Handley, M. 및 V. Jacobson, "SDP: 세션 설명
[7] Berners-Lee, T., Fielding, R. 및 L. Masinter, "URI(Uniform Resource Identifier): 일반 구문", STD 66, RFC 3986, 2005년 1월.
[8] Narten, T. 및 H. Alvestrand, "RFC에서 IANA 고려 사항 섹션 작성 지침", BCP 26, RFC 2434, 1998년 10월.
[9] Alvestrand, H., "언어 식별을 위한 태그", BCP 47, RFC 3066, 2001년 1월.
[10] Olson, S., Camarillo, G. 및 A. Roach, "세션 설명 프로토콜(SDP)에서 IPv6 지원", RFC 3266, 2002년 6월.
[11] Faltstrom, P., Hoffman, P. 및 A. Costello,
[12] Josefsson, S., "Base16, Base32 및 Base64 데이터 인코딩", RFC 3548, 2003년 7월.
[13] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[14] Handley, M., Perkins, C. 및 E. Whelan, "세션 발표 프로토콜", RFC 2974, 2000년 10월.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. 및 E. Schooler, "SIP: 세션 시작 프로토콜" , RFC 3261, 2002년 6월.
[16] Schulzrinne, H., Rao, A. 및 R. Lanphier, "실시간 스트리밍 프로토콜(RTSP)", RFC 2326, 1998년 4월.
[17] Rosenberg, J. 및 H. Schulzrinne, "세션 설명 프로토콜(SDP)을 사용한 제안/응답 모델", RFC 3264, 2002년 6월.
[18] Camarillo, G., Eriksson, G., Holler, J. 및 H. Schulzrinne, "세션 설명 프로토콜(SDP)의 미디어 라인 그룹화", RFC 3388, 2002년 12월.
[19] Schulzrinne, H., Casner, S., Frederick, R. 및 V. Jacobson, "RTP: 실시간 애플리케이션을 위한 전송 프로토콜", STD 64, RFC 3550, 2003년 7월.
[20] Schulzrinne, H. 및 S. Casner, "최소 제어를 통한 오디오 및 비디오 회의용 RTP 프로필", STD 65, RFC 3551, 2003년 7월.
[21] Casner, S., "RTCP 제어 프로토콜(RTCP) 대역폭을 위한 세션 설명 프로토콜(SDP) 대역폭 수정자", RFC 3556, 2003년 7월.
[22] Huitema, C., "SDP(세션 설명 프로토콜)의 RTCP(실시간 제어 프로토콜) 특성", RFC 3605, 2003년 10월.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E. 및 K. Norrman, "SRTP(보안 실시간 전송 프로토콜)", RFC 3711, 2004년 3월.
[24] Rosenberg, J., Schulzrinne, H. 및 P. Kyzivat, "SIP(Session Initiation Protocol)에서 사용자 에이전트 기능 표시", RFC 3840, 2004년 8월.
[25] Westerlund, M., "SDP(세션 설명 프로토콜)에 대한 전송 독립적 대역폭 수정자", RFC 3890, 2004년 9월.
[26] 국제 전기 통신 연합(International Telecommunication Union), "느슨하게 결합된 회의를 위해 확장된 H.323", ITU 권장 사항 H.332, 1998년 9월.
[27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. 및 K. Norrman, "SDP(세션 설명 프로토콜) 및 RTSP(실시간 스트리밍 프로토콜)에 대한 키 관리 확장", RFC 4567, 2006년 7월.
[28] Andreasen, F., Baugher, M. 및 D. Wing, "미디어 스트림에 대한 세션 설명 프로토콜(SDP) 보안 설명", RFC 4568, 2006년 7월.
[29] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[30] Hinden, R. 및 S. Deering, "IP 버전 6 주소 지정
[31] Freed, N. 및 J. Klensin, "미디어 유형 사양 및 등록 절차", BCP 13, RFC 4288, 2005년 12월.
Mark Handley University College London 컴퓨터 과학과 Gower Street London WC1E 6BT UK
EMail: M.Handley@cs.ucl.ac.uk
Van Jacobson
Packet Design
2465 Latham Street
Mountain View, CA 94040
USA
EMail: van@packetdesign.com
Colin Perkins University of Glasgow 컴퓨팅 과학과 17 Lilybank Gardens Glasgow G12 8QQ UK
EMail: csp@csperkins.org
Copyright (C) The Internet Society (2006).
이 문서는 BCP 78에 포함된 권리, 라이선스 및 제한 사항의 적용을 받으며 여기에 명시된 경우를 제외하고 작성자는 모든 권리를 보유합니다.
이 문서 및 여기에 포함된 정보는 "있는 그대로" 제공되며 기여자, 기여자가 대표하거나 후원하는 조직(있는 경우), 인터넷 사회 및 인터넷 공학 태스크포스는 모든 명시적 또는 묵시적 보증을 부인합니다. 여기에서 구성은 상품성 또는 특정 목적에의 적합성에 대한 권리 또는 묵시적 보증을 침해하지 않습니다.
IETF는 이 문서에 설명된 기술의 구현 또는 사용과 관련이 있다고 주장할 수 있는 지적 재산권 또는 기타 권리의 유효성 또는 범위 또는 그러한 권리에 따른 라이센스의 범위에 대해 어떠한 입장도 취하지 않습니다. 는 가능하다; 또한 그러한 권리를 식별하기 위해 독립적인 노력을 기울였다는 것을 나타내지 않습니다. RFC 문서의 권리와 관련된 절차에 대한 정보는 BCP 78 및 BCP 79에서 찾을 수 있습니다.
IETF 사무국에 제출된 IPR 공개 사본 및 사용 가능한 라이선스에 대한 보증 또는 이 사양의 구현자 또는 사용자가 이러한 독점권 사용에 대한 일반 라이선스 또는 허가를 얻으려는 시도의 결과를 얻을 수 있습니다. http://www.ietf.org/ipr의 IETF 온라인 IPR 저장소에서.
IETF는 이 표준을 구현하는 데 필요할 수 있는 기술을 포함할 수 있는 저작권, 특허 또는 특허 출원 또는 기타 소유권에 관심을 갖도록 이해 당사자를 초대합니다. 정보를 IETF(ietf-ipr@ietf.org)로 보내주십시오.
RFC 편집기 기능에 대한 자금은 IETF 행정 지원 활동(IASA)에서 제공합니다.
original document link : https://www.ietf.org/rfc/rfc4566.txt
Disclaimer of Accuracy for Translation:
This document is a translation of the original (RFC 4566). While every effort has been made to ensure the accuracy of this translation, it may contain errors or discrepancies. For verification of the content and to ensure consistency with the original document, please refer to the original version.
Non-Commercial Use and Educational Purpose Statement:
This translated document is intended solely for educational purposes and is not to be used for any commercial purposes. The content of this translation is provided to facilitate learning and understanding of the original (RFC 4566) and should not be utilized in any commercial context.
translator : yevgeny hong, used google translator api
contact : hongyevgeny@gmail.com