SIP 소개, Part 1: SIP이란
by Emmanuel Proulx
2006/02/07
개요
SIP(Session Initiation Protocol)는 통신 산업에서 매우 중요한 의미를 가지는 시그널링 프로토콜입니다. 본 기술 자료에서는 SIP에 대한 일반적인 사항과 기술적인 내용을 소개하며 통신 솔루션에서 SIP가 중요한 이유에 대해 설명합니다.
소개
얼마 전까지 애플리케이션 위에 "떠"있으면서 지원 기능을 제공하는 소프트웨어에 대한 가능성은 단지 아이디어에 지나지 않았습니다. 하지만 이제 이것은 단지 상상만이 아니라 분명히 실현 가능한 "지원" 시스템이 되었습니다. 기술 지원 상담원이 실시간으로 인터넷을 통해 컨퍼런스에 참여하도록 할 수도 있습니다. 얼마 전까지만 해도 이 아이디어를 실현할 툴, 라이브러리, 프로토콜, 대역폭 등이 존재하지 않았 습니다.
하지만 지금은 상황이 달라졌습니다.
많은 사람들은 DSL, 케이블 및 기타 다른 기술을 통해 가정 내에 브로드밴드를 갖추고 있습니다. 상용 소스든 오픈 소스든 간에 우수한 툴과 라이브러리가 풍부하고 애플리케이션을 가능하게 하는 표준이 지원됩니다. 이제 그 멋진 아이디어를 실현할 때입니다.
SIP의 일반 사항
먼저 SIP(Session Initiation Protocol)에 대해 소개하겠습니다. SIP는 두개의 엔드 포인트 간의 통신 세션을 시작하는 데 필요한 확장 가능하고 가벼운(lightweight) 요청/응답 프로토콜입니다. 지금 하는 설명이 여러분에게 친숙한 내용입니까? SIP는 비록 의도는 다르지만 HTTP와 SMTP에서 그 개념을 차용한 것입니다. SIP 메시지를 CB lingo 10-코드 및 Q-신호와 비교할 수 있습니다.
그림 1. CB 호출을 관리하는 데 사용되는 Lingo
이 예에서 실제 메시지는 특별한 호출 협상(negotiate) 메시지로 둘러 쌓여 있습니다.
SIP는 IETF에 의해 1999년 개발 및 제안되고, 2002년 개정되었습니다. 이에 대해서는 RFC 3261에 설명되어 있습니다. 본 기술 자료에서 소개하는 SIP 정보의 대부분은 이 RFC에서 추려낸 것입니다. SIP에 대한 많은 확장이 존재하며 이들 확장 중 상당수가 이 SIP 관련 RFC 및 초안 목록에 포함되어 있습니다.
SIP를 통해 얻을 수 있는 혜택은 무엇일까요? 일반적으로 SIP는 두 엔드 포인트에서 "호출"을 협상(negotiate)하기 위해 사용됩니다. 협상이라 하면 매체(텍스트, 음성, 기타), 전송 프로토콜(주로 RTP, Real Time Protocol) 및 인코딩(코덱)에서 각기 적합한 것을 결정한다는 것을 의미합니다. 협상이 성공하면 양 엔드 포인트에서는 SIP와 상관없이 선택된 방식을 사용하여 서로 대화합니다. "호출"이 종료되면 연결 해제를 알리기 위해 SIP가 사용됩니다. 이처럼 SIP는 시그널링 메커니즘으로서 가장 효과적으로 사용된다고 할 수 있습니다. SIP와 그 확장은 인스턴트 메시징, 등록 및 프리젠스(presence) 같은 관련 기능도 제공합니다.
SIP 전문 용어로 엔드 포인트를 사용자 에이전트라고 합니다. 이는 "소프트폰(soft phone)", 인스턴트 메신저, IP 폰, 심지어 휴대폰일 수도 있습니다. 중앙 집중식 서비스는 등록기, 프록시 또는 애플리케이션 서버와 같은 서버 사용자 에이전트에 의해 제공됩니다.
SIP는 매우 간단해 보이며 실제로도 그렇습니다. 하지만 이 단순성은 프로토콜의 안정성을 위해 매우 중요할 뿐 아니라 프로토콜의 실용성을 제한하지 않기 때문에 풍부한 활용 분야를 발굴해 낼 수 있었습니다.
예를 들어 HTTP를 생각해 보십시오. 이 프로토콜의 정의는 그 자체로는 사소하지만 사용 방법에는 한계가 없습니다. SIP 역시 확장이 가능합니다. 광범위한 애플리케이션을 망라하는 수십 가지의 SIP 확장이 이미 존재합니다. 이제 보다 자세하게 SIP를 논의하고 SIP가 중요한 이유를 살펴보겠습니다.
SIP는 중요한가?
통신에 있어서 SIP의 역할은 HTTP가 웹에서 수행하는 역할에 비견할 수 있다고 이미 언급하였습니다.
SIP는 통신 산업에 엄청난 반향을 일으키고 있습니다. 셀률러 기술 기업들은 향후의 모든 애플리케이션을 SIP로 표준화하기로 결정했습니다. VoIP(Voice over IP) 벤더, 인터넷 텔레포니 및 인스턴트 메시징 애플리케이션(예: Microsoft MSN Messenger)이 모두 SIP로 표준화되고 있습니다.
하지만 이미 시그널링 프로토콜과 P2P(peer-to-peer) 기술은 존재하고 있었습니다. 그렇다면 이제 SIP가 그들에게 어떤 혜택을 가져오는가 라는 질문이 제기될 것입니다. SIP는 다음과 같이 명확한 혜택을 제공합니다.
- 안정성: 이 프로토콜은 수년간 사용되고 있으며 확고하게 자리를 잡았습니다.
- 속도: 이 UDP 기반의 간단한 프로토콜은 놀라운 효율성을 제공합니다.
- 유연성: 이 텍스트 기반의 프로토콜은 쉽게 확장할 수 있습니다.
- 보안: 암호화(SSL, S/MIME) 및 인증과 같은 기능이 제공됩니다. SIP 확장은 기타 다른 보안 기능을 제공합니다.
- 표준화: 전체 통신 업계가 SIP로 이행하고 있으므로 SIP는 빠르게 표준으로 자리잡게 될 것입니다. SIP 보다 뛰어난 혜택을 제공하는 다른 기술도 존재할 수 있으나, 이들은 전세계적 범위에서 채택되지 못합니다.
여러분의 애플리케이션이 다른 툴, 장비 및 서버를 통합하기를 원한다면 SIP가 가장 좋은 방법입니다. 벤더들은 상호 운용성에 대해 우려하고 있기 때문에 정기적으로 모여 제품들을 테스트해 보고 있습니다. SIP 상호 운영성 테스트를 위한 이러한 모임을 SIPit(SIP Interoperability Tests)라 하며, 이 SIPit의 기존 명칭은 Bakeoff(Pillsbury의 소송으로 인하여 변경됨)입니다.
SIP 호출의 분석
이제 이 기술을 보다 면밀히 살펴봅시다. SIP는 SIP 툴에 의해 TCP가 지원되어야 함에도 불구하고 주로 UDP를 통해 전송됩니다. SIP메시지는 다음 두 부분으로 구성됩니다.
- 헤더 필드의 형식으로 요청 또는 요청 결과(응답)를 설명하는 엔빌로프(envelope)
- 요청에 대한 데이터를 포함하는 페이로드 옵션, 즉 컨텐츠
엔빌로프는 텍스트지만 컨텐츠는 텍스트이거나 바이너리입니다.
일례로 일반적인 SIP 호출을 집중적으로 살펴보겠습니다. 이 시나리오에서 User A는 User B에게 호출을 요청하려 합니다. 그림 2에서 이 호출에 대해 설명합니다.
그림 2. 일반적인 SIP 호출
모든 메시지는 다음과 같이 설명되어 있습니다.
| 1. User Agent A 는 SIP 요청 "INVITE"를 User Agent B에게 보내 User A가 User B와 대화하고 싶다는 의사를 알립니다. 이 요청에는 음성 스트리밍 프로토콜의 세부사항이 포함되어 있습니다. 이를 위해 페이로드에 Session Description Protocol(SDP)이 사용됩니다. SDP 메시지에는 User A에 의해 지원되는 모든 매체 코덱의 목록이 포함되어 있습니다. (이러한 코덱은 전송을 위해 RTP를 사용합니다.) | INVITE |
| 2. User Agent B가 요청을 읽고 User Agent A에게 요청을 수신했음을 알립니다. | SIP/2.0 |
| 3. 전화벨이 울리는 동안 User Agent B가 시간이 제한되거나 중단되지 않도록 프로비저널 메시지(벨 울림)를 User Agent A에게 보냅니다. | SIP/2.0 |
| 4. 결국 User B는 호출을 수락하기로 합니다. 이때 User Agent B가 User Agent A에게 OK 응답을 보냅니다. 응답 페이로드에는 또 다른 SDP 메시지가 포함됩니다. 여기에는 두 사용자 에이전트에 의해 지원되는 일련의 매체 코덱들이 포함됩니다. 이제 양측이 공식적으로 연결됩니다. 200이라는 타입의 응답으로 SIP 요청의 모든 타입이 수락됩니다. | SIP/2.0 |
| 5. 마지막으로 User Agent A가 ACK 메시지를 확인합니다. 메시지가 손실되는 경우에도 이 요청 타입에는 재시도와 응답 메시지가 없습니다. ACK는 INVITE 메시지의 경우에만 사용됩니다. | ACK |
| 6. 양측 사용자 에이전트는 이제 최종 SDP 메시지에서 선택된 방법을 사용하여 연결된 상태입니다. | PCMU/8000 인코딩을 사용하여 49170 및 3456 포트를 통해 양방향으로 이동하는 RTP 오디오 데이터 패킷 |
| 7. 통신 세션이 끝나면 사용자 중 한 명이 호출을 종료합니다. 이때 해당 사용자의 사용자 에이전트가 새로운 요청 BYE를 보내면 이 메시지가 상대에게 전송될 수 있습니다. | BYE |
| 8. 다른 사용자의 사용자 에이전트가 이 요청을 수락하고 OK 메시지로 응답합니다. 이제 호출의 연결이 해제됩니다. | SIP/2.0 |
SIP 메시지의 첫 줄에 메시지 타입과 사용되는 SIP 버전(2.0)이 포함됩니다. 요청에서 이 줄에 SIP URI라는 주소도 포함됩니다. 이 주소는 메시지의 수신지를 나타냅니다.
이 예제는 요청 메시지 INVITE, ACK, BYE와 응답 메시지 200 OK의 사용 방법에 대해 보여줍니다. SIP에는 많은 다른 메시지들이 존재합니다. 다음과 같은 몇 가지 요청이 있습니다.
| Message | Usage |
| INVITE | 사용자 에이전트에게 호출 요청, 호출 전송 |
| ACK | 호출 확인 |
| BYE | 호출 종료 |
| CANCEL | 아직 OK되지 않은 호출 종료 |
| REGISTER | 등록 서비스에 연락 주소와 대신 사용할 수 있는 별칭 제공. 예를 들어 주소 sip:UAA@example.com은 이전 예제에서 sip:UserA@10.20.30.40의 별칭입니다. 그 다음 등록 서버 example.com에서 UAA에 대한 호출을 주소 10.20.30.40으로 전달할 수 있습니다. |
| OPTIONS | 사용자 에이전트에게 "가능한 옵션(capabilities)"(예: 해당 에이전트가 이해하는 메시지와 코덱)을 요청합니다. |
다음은 자주 사용되는 응답 메시지들입니다.
| Message | Usage |
| 100 Trying | 이 메시지가 수신되어도 최종 사용자 에이전트에 의해 아직 처리되지 않습니다. 기다리십시오. |
| 180 Ringing | 이 메시지가 최종 사용자 에이전트에 의해 수신되어 해당 사용자에게 나타납니다. 기다리십시오. |
| 200 OK | 이 메시지가 최종 사용자에 의해 수락되었습니다. |
| 301 Moved Permanently & 302 Moved Temporarily | 사용자 에이전트의 주소가 변경되었습니다. Contact 필드에 새 영구 주소 또는 임시 주소가 있습니다. |
| 400 Bad Request | 일반 오류 메시지. 클라이언트가 이 메시지를 이해하지 못합니다. |
| 401 Unauthorized & 407 Proxy Authentication Required | 자격을 증명하고 다시 시도하십시오. |
| 404 Not Found | 연결하려는 사용자가 존재하지 않거나 등록되지 않았습니다. |
| 408 Request Timeout | 상대방이 응답하지 않습니다. 이는 SIP 메시지가 OK되지 않았을 뿐 아니라 모든 재시도가 실패했음을 의미합니다. 전화 벨이 너무 오랫동안 울렸다는 것을 의미하는 것이 아닙니다(전화 벨은 계속해서 울릴 수 있습니다). |
메시지들은 유사한 타입의 헤더 필드를 사용합니다. 그 중 일부가 다음에 소개되어 있습니다.
| Header field | Usage |
| From | SIP 요청 발신자 |
| To | SIP 요청 수신자. 이는 종종 SIP URI("별칭" 또는 실제 주소일 수 있음)와 동일합니다. |
| Contact | 사용자 에이전트의 실제 주소 |
| Call-ID | 발신자의 전화 번호가 아닙니다. 두 사용자 에이전트 간의 전체 호출, 즉 대화를 나타냅니다. 모든 관련 SIP 메시지는 동일한 Call-ID를 사용합니다. 예를 들어 사용자 에이전트가 BYE 메시지를 수신하면 Call-ID에 따라 종료할 호출을 알게 됩니다. |
| CSeq | 메시지의 순차 번호. 이는 단일 대화나 Call-ID 내에서만 사용되며 새 메시지와 "재시도"를 구분하기 위해 사용됩니다. 재시도는 초기 메시지가 해당 시간 내에 OK되지 못할 때 발생하며 일정 간격으로 실행됩니다. |
| Content-Type | 메시지 내부 페이로드의 MIME 타입 |
| Content-Length | 페이로드의 바이트 크기. 엔빌로프(envelope)와 페이로드는 한 줄을 띄어 구분합니다. |
Via, Route 및 Record-Route와 같이 메시지-라우팅 관련 기능을 처리하는 헤더도 존재합니다. Accept, User-Agent 및 Supported와 같은 헤더들은 가능한 옵션(capabilities)을 제공합니다. Authorization, Privacy 및 WWW-Authenticate와 같은 또 다른 헤더들은 보안을 제공합니다. 이 외에도 많은 헤더들이 존재합니다. 또한 이러한 필드의 대부분에는 짧은 구문(예, From = f, To = t 등)이 포함되어 있습니다.
그 외 SIP의 역할에는 어떤 것이 있습니까?
다음과 같이 SIP와 그 확장을 통해 구현할 수 있는 많은 애플리케이션이 있습니다.
- VoIP
- 비디오컨퍼런싱(화상회의)
- MSN Instant Messenger와 같은 텍스트 및 데이터용 인스턴트 메시징
- 등록(온라인!)
- 대화 상대 확인(대화 상대가 온라인 상태인가?)
- 클릭 투 토크(Click-to-talk)(클릭하여 기술 지원 상담원과 대화)
- 응답 시스템/IVR(Interactive Voice Response) 시스템("암호를 입력하십시오. 이름을 기록하십시오. 영어는 1번, 스페인어는 2번…을 누르십시오.")
- Quake와 일부 휴대폰 게임과 같은 네트워크로 연결된 게임(음성 및 IM 기반)
- Cell-phone-top 애플리케이션
- 모바일 e-비즈니스
기본적으로 두 엔드 포인트 간에 통신을 설정할 경우 SIP를 활용할 수 있습니다.
하지만 웹을 통한 실시간 기술 지원 상담원이라는 이 기발한 아이디어는 어떨까요? 지금 SIP를 통해 현실화할 수 있을까요? 그리고 필자가 애용하는 언어인 Java를 사용하여 이 작업을 수행할 수 있을까요? 간단히 대답한다면 "예"입니다.
Java를 사용한 SIP
필자는 SIP를 많이 사용합니다. 또한 Java가 SIP에 최상의 지원을 제공할 수 있다고 감히 말할 수 있습니다. SIP 개발자에게 유용한 Java 기술의 분류는 SIP 애플리케이션 개발과 관련된 많은 세부 사항들을 일목요연하게 구분합니다. 이들은 주로 다음과 같은 JAIN(Java APIs for Integrated Networks) 워크 그룹에 해당합니다.
- JAIN SIP API (JSR 32)
- SIP Servlet API (JSR 116)
- JAIN SIP Lite (JSR 125)
- SIP API for J2ME (JSR 180)
- JAIN SIMPLE Presence (JSR 164)
- JAIN SIMPLE Instant Messaging (JSR 165)
O그 외 다른 관련 기술들은 다음과 같습니다.
- JAIN SDP (JSR 141)
- Java Media Framework for RTP (JAIN이 아니라 J2SE 운영 패키지)
클라이언트 애플리케이션을 개발하려 한다면 클라이언트 측 SIP 엔진, 즉 "스택"이 필요합니다. 유용한 오픈 소스인 Java SIP 스택은 여기에서 제공됩니다. 또한 SDP도 지원합니다. 자체 SIP 폰을 개발하지 않으려면 이것을 사용할 수 있습니다.
결론
본 기술 문서에서는 SIP에 대한 간략한 소개에 덧붙여, 여러분이 사용할 수 있는 시나리오와 약간의 SIP 구문도 제공합니다. 아울러 SIP와 관련한 다양한 Java 기술도 살펴보았습니다. 물론 여기서 모든 것을 자세히 다루지는 못했지만 SIP에 대한 관심을 불러 일으키고 SIP 사용의 첫 발을 내딛게 하는 촉매로서의 역할을 했다면 그것으로 충분합니다. 이제 SIP의 시대가 도래했으며 수많은 멋진 아이디어들이 결국은 실현될 것입니다.
본 기술 자료 연작의 2부에서는 SIP 서블릿 API를 사용하여 대화방 애플리케이션을 작성하는 방법에 대해 소개하겠습니다.
참고자료
- SIP Forum - community site by the SIP working groups
- SIP Center - another popular community site
- RFC 3261 - SIP specification.
- SIP-related RFCs and drafts
- Open-source JAIN SIP stack
- Open-source SIP soft phone
Emmanuel Proulx는 J2EE 및 Enterprise JavaBeans의 전문가로서 인증된 WebLogic Server 7.0 엔지니어입니다.
'Protocol > SIP' 카테고리의 다른 글
| 초기화, reset, defaut 파일명 (0) | 2013.09.25 |
|---|---|
| Via, Record-Route, Route (Strict Routing, Loose Routing)의 차이 (0) | 2013.09.25 |
| overview sip (0) | 2013.09.25 |
| REGISTER (0) | 2013.09.25 |
| CANCEL (0) | 2013.09.25 |