| SIP(Session Initiation Protocol) |
SIP(Session Initiation Protocol)는 텍스트 기반의 응용 프로그램 계층 신호 및 호출 제어 프로토콜로, HTTP(HyperText transfer Protocol)와 유사합니다. SIP는 SIP 세션을 작성, 수정, 종료하는 데 사용되며, 유니캐스트 및 멀티캐스트 통신을 모두 지원합니다. SIP는 텍스트 기반이기 때문에 구현, 개발 및 디버깅이 H.323보다 간단합니다.
(H.323은 멀티미디어 화상회의 데이터를 TCP/IP와 같은 패킷 교환 방식의 네트웍을 통해 전송하기 위한 ITU-T의 표준이다. 여기에는 고품질 비디오를 위한 LAN 표준, 그리고 28.8 Kbps 정도의 느린 회선을 통해 저주파수 대역의 비디오를 전송하기 위한 인터넷 표준 등이 포함되어 있다.)
주요 SIP 환경 구성 요소는 두 가지 기본 범주인 SIP 서버와 SIP 사용자 에이전트로 구분됩니다.
SIP 서버
SIP 서버에는 프록시, 레지스터 및 리디렉션의 세 가지 유형이 있습니다. table 1에서와 같이 각 서버 유형은 다른 기능을 수행합니다. 서버가 수행하는 기능에 따라 처리되는 SIP 요청이 결정됩니다.
표 1 SIP 서버
| SIP 서버 | 기능 |
| 프록시 서버 | SIP 사용자 에이전트 클라이언트와 SIP 사용자 에이전트 서버 간의 중간 단계로 사용됩니다. 프록시 서버는 클라이언트와 서버 간의 통신 방향에 따라 SIP 사용자 에이전트 클라이언트나 SIP 사용자 에이전트 서버의 기능을 수행합니다. 프록시 서버는 SIP 요청을 전달하거나, SIP 요청을 전달하기 전에 수정할 수 있습니다. |
| 레지스터 서버 | 사용자 에이전트의 IP 주소와 SIP 주소, 즉 URL(Uniform Resource Locator)을 포함하는 REGISTER 요청을 수신합니다. 이를 통해 레지스터 서버는 REGISTER 요청을 보낸 사용자 에이전트의 위치를 추적할 수 있습니다. |
| 리디렉션 서버 | 호출 사용자 에이전트로부터 SIP 세션의 초기화를 SIP INVITE 요청의 형태로 수락하고, 호출된 사용자 에이전트의 올바른 SIP 주소를 검색하며, 해당 SIP 주소로 호출 사용자 에이전트에 응답합니다. 그런 다음 호출 사용자 에이전트는 해당 SIP 주소를 사용하여 호출된 사용자 에이전트와의 SIP 세션을 바로 시작합니다. |
SIP 서버(프록시, 레지스터 및 리디렉션)는 별도의 응용 프로그램으로 개발되거나, 모든 서버 기능을 결합하는 단일 응용 프로그램으로 개발될 수 있습니다. 레지스터 및 프록시 서버가 결합된 것을 종종 랑데부 서버라 합니다.
SIP 사용자 에이전트
표 2 에는 두 가지 유형의 SIP 사용자 에이전트와 그 기능이 나열되어 있습니다.
표 2 SIP 사용자 에이전트
| SIP 사용자 에이전트 | 기능 |
| 사용자 에이전트 클라이언트 | SIP 요청을 시작합니다. |
| 사용자 에이전트 서버 | SIP 요청을 수신합니다. |
각 사용자 에이전트는 SIP 주소와 연관됩니다.
SIP 호출 흐름
SIP 세션의 호출 흐름은 SIP 세션이 SIP 사용자 에이전트 간에 직접 설정되었는지 아니면 SIP 서버(프록시, 레지스터 또는 리디렉션)가 SIP 사용자 에이전트 사이에 있는지 여부에 따라 달라집니다.
그림 2는 두 사용자 에이전트 간의 일반적인 호출 흐름을 보여 주며 각 단계는 괄호로 되어 있습니다. 우선 사용자 에이전트 A는 호출을 시작하기 위해 INVITE 요청을 보냅니다. 그러면 사용자 에이전트 B는 호출 요청이 처리 중임을 나타내는 시도 중 응답 코드(100)로 응답합니다. 사용자 에이전트 B가 호출을 수락했음을 나타내는 확인 응답 코드(200)로 응답하면 사용자 에이전트 A는 사용자 에이전트 B의 최종 응답 코드를 사용자 에이전트 A가 수신했음을 나타내는 승인(ACK) 요청으로 사용자 에이전트 B에 응답합니다. 문서 뒷부분에 나오는 'RTP 및 RTCP'에서 설명하는 바와 같이, 실시간 데이터가 RTP 패킷으로 캡슐화 되어 사용자 에이전트 A와 B 사이에 전송되고 나면, 사용자 에이전트 A 또는 B는 사용자 에이전트가 세션을 종료하고자 함을 나타내는 BYE 요청을 보낼 수 있습니다. 그러면 사용자 에이전트 B는 요청 성공을 나타내는 확인 응답 코드(200)를 사용자 에이전트 A에게 보냅니다.
그림 2 사용자 에이전트 SIP 호출 흐름
그림 3은 두 사용자 에이전트 경로 사이에 프록시 서버가 있을 경우의 일반적인 호출 흐름을 보여 줍니다. 프록시 서버는 기본적으로 사용자 서버 및 사용자 에이전트의 기능을 모두 수행하는 통신 중간 지점으로 사용됩니다. 사용자 서버로 작동할 경우 프록시는 SIP 요청을 수신하여 대상 사용자 에이전트로 전달하고, 사용자 에이전트로 작동할 경우 SIP 응답을 수신하여 대상 사용자 에이전트로 전달합니다
그림 3 프록시 서버 SIP 호출 흐름
그림 4는 사용자 에이전트와 레지스터 서버 간의 일반적인 호출 흐름을 보여 줍니다. 레지스터 서버는 사용자 에이전트가 도달할 수 있는 주소를 나타내는 사용자 에이전트의 REGISTER 요청을 수락합니다. 레지스터 서버는 일반적으로 프록시 또는 리디렉션 서버와 함께 위치합니다.
그림 4 관리자 서버 SIP 호출 흐름
그림 5는 리디렉션 서버가 두 사용자 에이전트 사이에 있을 경우의 일반적인 호출 흐름을 보여 줍니다. 사용자 에이전트 A가 호출을 시작하기 위해 INVITE 요청을 보내면, 리디렉션 서버는 사용자 에이전트 B가 일시적으로 이동했음을 나타내는 이동됨 응답 코드(302)로 응답합니다. 이어서 사용자 에이전트 A는 리디렉션 서버의 응답 코드를 사용자 에이전트 A가 수신했음을 나타내는 ACK 요청으로 응답합니다. 그러면 사용자 에이전트 A는 사용자 에이전트 B의 새로 얻은 주소로 또 다른 INVITE 요청을 바로 보냅니다.
그림 5 리디렉션 서버 SIP 호출 흐름
샘플 SIP 아키텍처
그림 6은 샘플 SIP 아키텍처를 사용하여, SIP 구성 요소 간 통신이 처리되는 방법 및 SIP 구성 요소를 네트워크 환경에 맞추는 방법을 설명합니다.
그림 6 샘플 SIP 아키텍처
A. Datum Corporation은 회사 내 도메인 간에 SIP 요청을 전달하는 두 개의 SIP 프록시 서버를 가지고 있습니다. 방화벽에 연결된 SIP 프록시 서버는 회사 외부의 수신자에게 보내지는 모든 SIP 메시지와 회사 외부에서 내부의 수신자에게 보내지는 모든 메시지를 처리합니다. 예를 들어, A. Datum Corporation의 SIP 클라이언트에서 Fabrikam, Inc.의 SIP 클라이언트에게 전송되는 SIP INVITE 메시지는 Fabrikam, Inc.의 SIP 프록시 서버로 보내집니다.
그런 다음 SIP 프록시 서버는 SIP INVITE 요청을 Fabrikam, Inc.의 SIP 프록시 서버 도메인에 있는 대상 SIP 클라이언트 컴퓨터나 SIP IP 전화로 전달합니다. 예를 들어, Fabrikam, Inc.의 SIP 서버는 국제 전화 번호 형식으로 SIP URL과 함께 보내진 SIP INVITE 요청을 수신할 수 있습니다. 국제 전화 번호에 Fabrikam, Inc.의 SIP IP 전화 대상이 있을 경우 SIP INVITE 요청은 SIP IP 전화로 바로 전달됩니다. 반면, 국제 전화 번호에 아날로그 전화와 같은 SIP IP 전화 외의 대상이 있을 경우 SIP INVITE 요청은 PSTN에 맞게 SIP INVITE 요청의 서식을 지정하는 SIP/PSTN 게이트웨이로 전달됩니다. 회사의 PBX(Private Branch Exchange)는 국제 전화 번호를 사용하여 호출을 회사 내의 아날로그 전화로 라우팅할 것인지 아니면 회사 외부의 아날로그 전화용 PSTN으로 라우팅할 것인지를 결정합니다.
SIP 프로토콜
SIP 메시지는 RFC 822, 'Standard for the Format of ARPA Internet Text Messages'에 설명되어 있는 바와 같이 table준 인터넷 메시지 형식에 기초합니다. (http://www.microsoft.com/windows/reskits/webresources/ 
의 웹 리소스 페이지 참조) SIP 메시지는 클라이언트에서 서버로 보내지는 요청이나 서버에서 클라이언트로 보내지는 응답입니다.
각 SIP 메시지는 표 3에서 보는 바와 같이 세 부분으로 구성됩니다.
표 3 SIP 메시지 부분
| SIP 메시지 부분 | 정의 |
| 시작 줄 | 메시지가 요청인지 아니면 응답인지에 따라 콘텐트가 달라집니다. 요청 및 응답 시작 줄은 모두 SIP 버전을 포함합니다. 또한 요청 시작 줄은 메서드 유형과 요청을 수신하는 대상의 일반 URL 또는 SIP 주소를 포함하며 응답 시작 줄은 요청에 대한 응답을 정의하는 숫자 상태 코드와 응답구를 포함합니다. |
| 헤더 | 헤더 유형과 관련 변수를 포함합니다. |
| 메시지 본문 | SDP(Session Description Protocol)에서 제공한 정보(예: SIP 세션의 미디어 기능에 대한 설명)를 포함합니다. |
SIP는 시작 줄과 헤더의 값을 정의하며 SDP(Session Description Protocol)는 메시지 본문 값을 정의합니다.
SIP 메시지 시작 줄
표 4에 설명되어 있는 바와 같이 시작 줄 구문은 메시지가 요청인지 응답인지에 따라 달라집니다.
표 4 시작 줄 구문
| 시작 줄 | 구문 |
| 요청 | 메서드, 요청 URI, SIP 버전 |
| 응답 | SIP 버전, 상태 코드, 응답구 |
요청 메서드
요청 시작 줄의 첫 번째 항목은 신호 명령인 SIP 메서드입니다. table 5에 나열된 SIP 메서드는 RFC 3261, 인터넷 초안 'SIP Extensions for Presence' 및 'SIP Extensions for Instant Messaging'에 정의되어 있습니다.
표 5 SIP 메서드 및 그 기능
| SIP 메서드 | 기능 |
| INVITE | SIP 세션을 시작하기 위한 요청입니다. INVITE는 발신자로부터 수신자에게 보냅니다. |
| ACK | 수신자가 호출을 수락했습니다. ACK는 발신자로부터 수신자에게 보내집니다. |
| OPTIONS | 발신자가 수신자에게 자체 기능으로 응답할 것을 요청하고 있습니다. |
| BYE | 세션을 종료하기 위한 요청입니다. BYE는 발신자나 수신자가 보낼 수 있습니다. BYE를 수신하는 당사자가 BYE로 응답할 필요는 없습니다. |
| CANCEL | 일시 중지된 요청을 취소합니다. |
| REGISTER | 발신자가 현재 위치를 관리자 서버에 등록하기를 원합니다. |
| SUBSCRIBE | 발신자가 수신자의 상태 정보에 대한 업데이트를 요청합니다. |
| NOTIFY | 자신의 업데이트된 상태를 가입한 당사자 자체에 전달합니다. |
| MESSAGE | 인스턴트 메시지를 보내는 데 사용됩니다. |
요청 URI
요청 시작 줄의 두 번째 항목은 수신자 URL을 포함하는 요청 URI(Uniform Resource Identifier)입니다. 일반적으로 이 URI는 여러 형식 중 하나를 가질 수 있는 SIP URL입니다. table 6에는 지원되는 형식 중 일부가 나열되어 있습니다.
표 6 SIP 요청 URL 형식의 일부 목록
| SIP URL 형식 | 설명 |
| sip:user@reskit.com | 기본 SIP URL입니다. |
| sip:user@reskit.com;transport=TCP | TCP의 전송 프로토콜 대상을 포함하는 기본 SIP URL입니다. 전송 프로토콜이 지정되지 않은 경우 기본값은 UDP입니다. |
| sip:user@172.16.20.54 | IP 주소를 포함하는 SIP URL입니다. |
| sip:+1-425-707-9796@reskit.com;user=phone | 국제 전화 번호를 포함하는 SIP URL입니다. |
| sip:marketing@reskit.com;maddr=225.0.2.1;ttl=64 | 이전에 지정된 호스트 이름을 무시하는 멀티캐스트 주소를 포함하는 SIP URL입니다. TTL(Time-To-Live) 값은 64(0-255)로 설정됩니다. 멀티캐스트 주소와 UDP를 전송 프로토콜로 사용할 경우 TTL을 설정해야 합니다. |
요청 또는 응답 버전
요청 시작 줄의 마지막 항목이자 응답 시작 줄의 첫 번째 항목은 SIP 버전(현재 2.0)입니다.
Windows Messenger 세션에서 가져온 다음 샘플 SIP 요청 메시지는 일반적인 SIP 요청 줄을 보여 줍니다.
응답 상태 코드
상태 코드에는 정보, 성공, 리디렉션, 클라이언트 오류, 서버 오류 및 전역 실패의 6개 범주가 있습니다. table 7에 나온 것처럼 상태 코드의 맨 왼쪽 숫자는 코드의 범주를 나타냅니다.
표 7 SIP 응답 상태 코드
| 상태 코드 | 응답 범주 | 설명 |
| 1xx | 정보 | 요청이 수신되었으며 처리 중입니다. |
| 2xx | 성공 | 요청된 작업을 성공적으로 이해 및 수락했습니다. |
| 3xx | 리디렉션 | 요청을 완료하기 위해 추가 작업이 필요합니다. |
| 4xx | 클라이언트 오류 | 요청에 잘못된 구문이 포함되어 있거나 서버에서 요청을 이행할 수 없습니다. |
| 5xx | 서버 오류 | 서버가 요청을 수신했지만 이를 처리할 수 없으며 다른 서버의 경우에는 요청을 처리할 수도 있습니다. |
| 6xx | 전역 실패 | 요청을 수신하는 서버에서 이를 처리할 수 없으며 다른 서버에서도 요청이 실패할 것입니다. 따라서 요청을 전달해서는 안 됩니다. |
응답구
표 8에는 SIP 버전 2.0에 정의된 모든 SIP 응답 코드와 해당 범주 및 응답구가 나열되어 있습니다.
표 8 SIP 응답 상태 코드 및 응답구
| 상태 코드 | 응답 범주 | 응답구 |
| 100 | 정보 | 시도 중 |
| 180 | 정보 | 신호가 울림 |
| 181 | 정보 | 호출 전달 중 |
| 182 | 정보 | 대기 |
| 200 | 성공 | 확인 |
| 300 | 리디렉션 | 다중 선택 |
| 301 | 리디렉션 | 영구적으로 이동됨 |
| 302 | 리디렉션 | 임시로 이동됨 |
| 303 | 리디렉션 | 기타 참조 |
| 305 | 리디렉션 | 프록시 사용 |
| 380 | 리디렉션 | 대체 서비스 |
| 400 | 클라이언트 오류 | 잘못된 요청 |
| 401 | 클라이언트 오류 | 권한이 없음 |
| 402 | 클라이언트 오류 | 지불 필요 |
| 403 | 클라이언트 오류 | 사용할 수 없음 |
| 404 | 클라이언트 오류 | 없음 |
| 405 | 클라이언트 오류 | 메서드 허용 안 함 |
| 406 | 클라이언트 오류 | 받아들일 수 없음 |
| 407 | 클라이언트 오류 | 프록시 인증 필요 |
| 408 | 클라이언트 오류 | 요청 시간 초과 |
| 409 | 클라이언트 오류 | 충돌 |
| 410 | 클라이언트 오류 | 없음 |
| 411 | 클라이언트 오류 | 길이 필요 |
| 413 | 클라이언트 오류 | 요청 엔터티가 너무 큼 |
| 414 | 클라이언트 오류 | 요청 URI가 너무 김 |
| 415 | 클라이언트 오류 | 지원되지 않는 미디어 유형 |
| 420 | 클라이언트 오류 | 잘못된 확장 |
| 480 | 클라이언트 오류 | 일시적으로 사용할 수 없음 |
| 481 | 클라이언트 오류 | 호출 레그/트랜잭션 없음 |
| 482 | 클라이언트 오류 | 검색된 루프 |
| 483 | 클라이언트 오류 | 홉이 너무 많음 |
| 484 | 클라이언트 오류 | 주소가 완전하지 않음 |
| 485 | 클라이언트 오류 | 모호함 |
| 486 | 클라이언트 오류 | 여기에서 사용 중 |
| 500 | 서버 오류 | 서버 내부 오류 |
| 501 | 서버 오류 | 구현되지 않음 |
| 502 | 서버 오류 | 잘못된 게이트웨이 |
| 503 | 서버 오류 | 서비스 사용할 수 없음 |
| 504 | 서버 오류 | 게이트웨이 시간 초과 |
| 505 | 서버 오류 | 지원되지 않는 SIP 버전 |
| 600 | 전역 실패 | 모든 곳에서 사용 중 |
| 603 | 전역 실패 | 적용 안 함 |
| 604 | 전역 실패 | 어느 곳에도 없음 |
| 606 | 전역 실패 | 받아들일 수 없음 |
SIP 메시지 헤더
SIP 메시지의 시작 줄 다음에는 하나 이상의 헤더가 옵니다. 포함된 헤더는 메시지가 응답인지, 요청인지에 따라 다릅니다. 헤더는 RFC 3261, 'SIP: Session Initiation Protocol'에 정의되어 있습니다. (http://www.microsoft.com/windows/reskits/webresources/ 의 웹 리소스 페이지 참조)
표 9에 나온 것처럼 헤더는 일반, 요청, 응답 및 엔터티의 네 가지 범주로 구분됩니다. 일반 범주의 헤더는 요청 및 응답 메시지 모두에 사용할 수 있습니다.
표 9 SIP 헤더
| 일반 | 요청 | 응답 | 엔터티 |
| Accept | Authorization | Allow | Content-encoding |
| Accept-encoding | Contact | Proxy-authenticate | Content-length |
| Accept-language | Hide | Retry-after | Content-type |
| Call-ID | Max-forwards | Server | |
| Contact | Organization | Unsupported | |
| Cseq | Priority | Warning | |
| Date | Proxy-authorization | WWW-authenticate | |
| Encryption | Proxy-require | ||
| Expires | Route | ||
| From | Require | ||
| Record-route | Response-key | ||
| Time stamp | Subject | ||
| To | User-agent | ||
| Via |
Windows Messenger 세션에서 가져온 다음의 샘플 SIP 요청에서는 SIP 헤더가 강조 table시되어 있습니다.
SIP 메시지 본문은 SDP(Session Description Protocol)에 의해 정의됩니다.
| SDP(Session Description Protocol) |  |
 | |
SDP(Session Description Protocol)는 멀티미디어 회의를 알리고 설명하기 위한 IETF table준입니다. SIP 메시지 본문에는 SDP에 의해 정의된 바와 같이 세션 설명이 포함되어 있습니다. 세션 설명은 단일 세션 설명, 0개 이상의 시간 설명 및 0개 이상의 미디어 설명의 세 부분으로 구성됩니다. 세션 설명은 전체 회의나 모든 미디어 스트림에 적용되는 전역 특성을 포함하고, 시간 설명은 회의 시작, 중지 및 반복 시간 정보를 포함하며, 미디어 설명은 특정 미디어 스트림에 대한 세부 정보를 포함합니다. table 10에는 SDP 메시지의 각 부분에서 사용할 수 있는 SDP 유형과 관련 설명 값이 나열되어 있습니다.
표 10 SDP 설명
| 세션 | 시간 | 미디어 | |||
| 유형 | 값 | 유형 | 값 | 유형 | 값 |
| v | 프로토콜 버전 | t | 세션이 활성화되는 시간 | m | 미디어 이름 및 전송 주소 |
| o | 소유자/작성자 및 세션 식별자 | r | 0 이상의 반복 횟수 | i | 미디어 제목 |
| s | 세션 이름 | c | 연결 정보 | ||
| i | 세션 정보 | b | 대역폭 정보 | ||
| u | 설명 URI(Uniform Resource Identifier) | k | 암호화 키 | ||
| e | 전자 메일 주소 | a | 0개 이상의 미디어 특성 줄 | ||
| p | 전화 번호 | ||||
| c | 연결 정보 | ||||
| b | 대역폭 정보 | ||||
| z | table준 시간대 조정 | ||||
| a | 0개 이상의 세션 특성 줄 | ||||
Windows Messenger 세션에서 가져온 다음의 샘플 SIP 요청 메시지에서는 SIP 메시지 본문이 강조 table시되어 있습니다.
출저(좀 지난 자료지만 SIP에 대한 대략적인 내용이해에 도움이 되었음):
http://www.microsoft.com/korea/technet/prodtechnol/winxppro/plan/rtcprot.mspx
