세션 개시 프로토콜

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 프로토콜 동작
4. 네트워크 구성 요소
5. SIP 메시지
- 5.1. 요청 (Requests)
- 5.2. 응답 (Responses)
6. 트랜잭션
7. 인스턴트 메시징 및 프레즌스
8. 상호 운용성 및 적합성 테스트
9. 성능 테스트
10. 응용 분야
11. 구현
12. SIP-ISUP 상호 연동
13. 암호화
참조

1. 개요

세션 개시 프로토콜(SIP)은 IP 기반 통신을 위한 신호 제어 프로토콜로, 음성, 화상 통화 설정 및 종료에 주로 사용된다. 1996년 처음 설계되어 1999년 표준화되었으며, 3GPP 신호 프로토콜로 채택되어 IP 멀티미디어 서브시스템(IMS) 아키텍처의 핵심 요소가 되었다. SIP는 텍스트 기반의 HTTP와 유사한 구조를 가지며, 다양한 멀티미디어 애플리케이션과 인스턴트 메시징, 프레즌스 정보 등으로 확장되었다. SIP 네트워크는 사용자 에이전트, 프록시 서버, 리다이렉트 서버, 등록 서버, 세션 경계 제어기, 게이트웨이 등의 구성 요소로 이루어져 있으며, SIP URI를 사용하여 자원을 식별한다. SIP는 HTTP와 유사한 요청 및 응답 트랜잭션 모델을 사용하며, 전송 계층 프로토콜인 TCP, UDP, SCTP를 통해 전송된다. SIP는 인스턴트 메시징 및 현황 정보를 위한 SIMPLE 표준과도 연동되며, SIP 연결 및 트렁킹, 비디오 감시, IP 기반 오디오 등 다양한 분야에 활용된다.

더 읽어볼만한 페이지

VoIP 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
VoIP 프로토콜 - VoiceXML
VoiceXML은 음성 브라우저에게 음성 합성, 자동 음성 인식, 대화 관리, 오디오 재생을 지시하는 XML 기반 마크업 언어로서, 다양한 산업 분야에서 음성 인터페이스 구축에 사용되었으며, 관련 표준과 함께 1999년 개발 후 W3C로 표준 관리가 이관되었으나 현재는 새로운 표준 개발이 중단되었다.
응용 계층 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
응용 계층 프로토콜 - D-Bus
D-Bus는 2002년에 시작된 프로세스 간 통신 시스템으로, 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다.
화상 통화 - 시스코 시스템즈
시스코 시스템즈는 1984년 설립되어 네트워킹 장비 및 서비스를 제공하는 다국적 기업으로, 라우팅 기술을 기반으로 성장하여 사업 다변화를 추진하며 여러 논란에 직면해 있다.
화상 통화 - 삼성전자
삼성전자는 1969년 설립된 대한민국의 전자제품 제조 기업으로, 가전제품 생산에서 시작하여 반도체, 스마트폰 시장으로 사업을 확장하며 메모리 반도체 및 TV 시장에서 세계 1위를 유지하고 있다.

세션 개시 프로토콜
세션 개시 프로토콜
목적	인터넷 전화
날짜	1999년 3월
OSI 계층	응용 계층 (7계층)
포트	5060, 5061
RFC	2543, 3261

2. 역사

세션 개시 프로토콜(SIP)은 1996년 마크 핸들리, 헤닝 슐츠린네, 이브 스쿨러, 조나단 로젠버그가 처음 설계했으며, Mbone에서 멀티캐스트 멀티미디어 세션을 쉽게 설정할 수 있도록 했다. 이 프로토콜은 1999년 RFC 2543으로 표준화되었다. 2000년 11월, SIP는 3GPP 신호 프로토콜로 채택되었고, 셀룰러 네트워크에서 IP 기반 스트리밍 멀티미디어 서비스를 위한 IP 멀티미디어 서브시스템(IMS) 아키텍처의 영구적인 요소가 되었다. 2002년 6월에는 RFC 3261^[3]로 개정되었으며, 이후 다양한 확장 및 설명이 발표되었다.^[4]

SIP는 IP 기반 통신을 위한 신호 및 통화 설정 프로토콜을 제공하며, 공중 전화망(PSTN)에 존재하는 통화 처리 기능과 특징을 새로운 멀티미디어 애플리케이션에 지원하는 것을 목표로 한다. 화상 회의, 스트리밍 미디어 배포, 인스턴트 메시징, 프레즌스 정보, 파일 전송, 인터넷 팩스, 온라인 게임 등 다양한 분야로 확장되었다.^[5]^[6]^[7]

SIP는 통신 산업보다는 인터넷 커뮤니티에 기반을 두고 있다는 점에서 차별화된다. 주로 인터넷 기술 표준화 기구(IETF)에 의해 표준화되었으며, H.323과 같은 다른 프로토콜은 전통적으로 국제 전기 통신 연합(ITU)과 관련되어 있다.

2. 1. 개발 배경 및 초기 표준화

SIP는 1996년 마크 핸들리, 헤닝 슐츠린네, 이브 스쿨러, 조나단 로젠버그에 의해 처음 설계되었으며, Mbone에서 멀티캐스트 멀티미디어 세션을 설정하는 것을 용이하게 했다. 이 프로토콜은 1999년에 표준화되었다. 2000년 11월, SIP는 3GPP 신호 프로토콜로 채택되었고, 셀룰러 네트워크에서 IP 기반 스트리밍 멀티미디어 서비스를 위한 IP 멀티미디어 서브시스템 (IMS) 아키텍처의 영구적인 요소가 되었다. 2002년 6월에 사양이 개정되었으며^[3], 이후 다양한 확장 및 설명이 발표되었다.^[4]

SIP는 IP 기반 통신을 위한 신호 및 통화 설정 프로토콜을 제공하도록 설계되었으며, 새로운 멀티미디어 애플리케이션을 지원한다는 비전을 가지고 공중 전화망 (PSTN)에 존재하는 통화 처리 기능과 특징을 지원한다. 화상 회의, 스트리밍 미디어 배포, 인스턴트 메시징, 프레즌스 정보, 파일 전송, 인터넷 팩스, 온라인 게임으로 확장되었다.^[5]^[6]^[7]

SIP는 통신 산업보다는 인터넷 커뮤니티에 뿌리를 두고 있다는 점에서 지지자들에 의해 구별된다. SIP는 주로 인터넷 기술 표준화 기구 (IETF)에 의해 표준화되었으며, H.323과 같은 다른 프로토콜은 전통적으로 국제 전기 통신 연합 (ITU)과 연관되어 있다.

2. 2. 3GPP 채택 및 IMS 통합

SIP는 1996년 마크 핸들리, 헤닝 슐츠린네, 이브 스쿨러, 조나단 로젠버그에 의해 처음 설계되었으며, 1999년 IETF RFC 2543으로 표준화되었다. 2000년 11월, SIP는 3GPP 신호 프로토콜로 채택되었고, 셀룰러 네트워크에서 IP 기반 스트리밍 멀티미디어 서비스를 위한 IP 멀티미디어 서브시스템(IMS) 아키텍처의 영구적인 요소가 되었다. 2002년 6월에 사양이 IETF RFC 3261^[3]에서 개정되었으며, 이후 다양한 확장 및 설명이 발표되었다.^[4]

2. 3. 지속적인 발전과 확장

SIP는 1996년 마크 핸들리, 헤닝 슐츠린네, 이브 스쿨러, 조나단 로젠버그에 의해 처음 설계되었으며, Mbone에서 멀티캐스트 멀티미디어 세션을 설정하는 것을 용이하게 했다. 이 프로토콜은 1999년 RFC 2543으로 표준화되었다. 2000년 11월, SIP는 3GPP 신호 프로토콜로 채택되었고, 셀룰러 네트워크에서 IP 기반 스트리밍 멀티미디어 서비스를 위한 IP 멀티미디어 서브시스템 (IMS) 아키텍처의 영구적인 요소가 되었다. 2002년 6월에 사양이 RFC 3261^[3]에서 개정되었으며, 이후 다양한 확장 및 설명이 발표되었다.^[4]

SIP는 IP 기반 통신을 위한 신호 및 통화 설정 프로토콜을 제공하도록 설계되었으며, 새로운 멀티미디어 애플리케이션을 지원한다는 비전을 가지고 공중 전화망 (PSTN)에 존재하는 통화 처리 기능과 특징을 지원한다. 화상 회의, 스트리밍 미디어 배포, 인스턴트 메시징, 프레즌스 정보, 파일 전송, 인터넷 팩스, 온라인 게임으로 확장되었다.^[5]^[6]^[7]

SIP는 통신 산업보다는 인터넷 커뮤니티에 뿌리를 두고 있다는 점에서 지지자들에 의해 구별된다. SIP는 주로 인터넷 기술 표준화 기구 (IETF)에 의해 표준화되었으며, H.323과 같은 다른 프로토콜은 전통적으로 국제 전기 통신 연합 (ITU)과 연관되어 있다.

2. 4. IETF와 ITU

SIP는 1996년 마크 핸들리, 헤닝 슐츠린네, 이브 스쿨러, 조나단 로젠버그에 의해 처음 설계되었으며, Mbone에서 멀티캐스트 멀티미디어 세션을 설정하는 것을 용이하게 했다. 이 프로토콜은 1999년에 표준화되었다. 2000년 11월, SIP는 3GPP 신호 프로토콜로 채택되었고, 셀룰러 네트워크에서 IP 기반 스트리밍 멀티미디어 서비스를 위한 IP 멀티미디어 서브시스템 (IMS) 아키텍처의 영구적인 요소가 되었다. 2002년 6월에 사양이 개정되었으며,^[3] 이후 다양한 확장 및 설명이 발표되었다.^[4]

SIP는 IP 기반 통신을 위한 신호 및 통화 설정 프로토콜을 제공하도록 설계되었으며, 새로운 멀티미디어 애플리케이션을 지원한다는 비전을 가지고 공중 전화망 (PSTN)에 존재하는 통화 처리 기능과 특징을 지원한다. 화상 회의, 스트리밍 미디어 배포, 인스턴트 메시징, 프레즌스 정보, 파일 전송, 인터넷 팩스, 온라인 게임으로 확장되었다.^[5]^[6]^[7]

SIP는 통신 산업보다는 인터넷 커뮤니티에 뿌리를 두고 있다는 점에서 지지자들에 의해 구별된다. SIP는 주로 인터넷 기술 표준화 기구 (IETF)에 의해 표준화되었으며, H.323과 같은 다른 프로토콜은 전통적으로 국제 전기 통신 연합 (ITU)과 연관되어 있다.

3. 프로토콜 동작

SIP(세션 개시 프로토콜)는 H.323을 대체하는 범용 세션 제어 프로토콜로서, DynamicSoft(당시)의 J. 로젠버그 등을 중심으로 개발되었다. 여기서 말하는 "세션"은 OSI 참조 모델에서 규정하는 제5계층과는 다른 의미이다. SIP의 주요 용도는 전화, 화상 전화나 인스턴트 메시징과 같은 양방향 실시간 통신이다.

실시간 멀티미디어 데이터 통신 프로토콜인 H.323과 비교했을 때, SIP는 다음과 같은 특징을 가진다.

세션의 시작, 변경, 종료만 수행하므로 단순하다.
HTTP 1.1과 유사한 텍스트 기반 메시지 형식을 사용하므로 소프트웨어의 기능 추가 및 확장이 용이하다.
인터넷 아키텍처에서 전화 등 세션을 제어하기 위한 프로토콜이다. 기존 전화 제어는 네트워크 중심에 있는 교환기에 의한 집중 제어 방식으로 구현되어 있어, 단말 측에서 쉽게 서비스를 추가할 수 없었다. 이에 반해 인터넷 아키텍처에서는 네트워크는 정보를 전달하는 역할에 집중하고, 단말 측에서 서비스를 임의로 추가할 수 있다. SIP로 전화 시스템을 구축함으로써, 인터넷과 마찬가지로 사용자가 단말 측에서 자유롭게 전화 서비스 (영상 포함)를 추가할 수 있게 된다. 참고로 H.323은 IP를 통해 전화, 영상 등의 접속 제어를 수행하는 규약이지만, 집중 제어형 신호 방식이므로 기존 교환기 아키텍처와 동일하다.

SIP는 이러한 실시간 통신에서 기본적으로 통신자가 대등하며, 서버와 클라이언트와 같은 역할 분담은 존재하지 않는다. SIP에서는 이를, 양자가 서버와 클라이언트의 기능을 함께 갖는 형태로 표현하고 있다. 즉, SIP는 HTTP를 바탕으로 만들어졌기 때문에 기본적으로 요청-응답형 프로토콜이며, 요청자와 응답자가 모두 이 두 가지 역할을 모두 수행할 수 있다.

3. 1. 기본 원리

두 사용자, 앨리스와 밥 사이의 SIP 메시지 교환 예시로, 직접적인 미디어 세션을 설정하고 종료한다.

SIP는 음성 또는 화상 통화와 같은 미디어 통신 세션의 신호 제어에만 관여하며, 주로 이러한 통화를 설정하고 종료하는 데 사용된다. SIP는 2자 통신(유니캐스트) 또는 다자 통신(멀티캐스트) 세션을 설정할 수 있으며, 기존 통화를 수정하는 것도 가능하다. 수정에는 주소나 포트 변경, 참가자 초대, 미디어 스트림 추가 또는 삭제 등이 포함될 수 있다. SIP는 인스턴트 메시징, 이벤트 구독 및 알림과 같은 메시징 애플리케이션에도 사용된다.

SIP는 통화 설정 후 미디어 형식 및 코딩을 지정하고 미디어를 전송하는 여러 다른 프로토콜과 함께 작동한다. 통화 설정을 위해 SIP 메시지에는 세션 설명 프로토콜(SDP) 데이터 단위가 포함되어 미디어 형식, 코덱, 미디어 통신 프로토콜을 지정한다. 음성 및 화상 미디어 스트림은 일반적으로 실시간 전송 프로토콜(RTP) 또는 보안 실시간 전송 프로토콜(SRTP)을 사용하여 전송된다.^[2]^[8]

SIP 네트워크의 모든 리소스(사용자 에이전트, 통화 라우터, 음성 사서함 등)는 통합 자원 식별자(URI)로 식별된다. URI는 웹 서비스 및 이메일에서 사용되는 일반 표준 구문을 따른다.^[9] SIP URI 스킴은 ''sip''이며, 일반적인 SIP URI는 ''sip:username@domainname'' 또는 ''sip:username@hostport'' 형식을 갖는다. 여기서 ''domainname''은 SIP 도메인 서버를 찾기 위한 DNS SRV 레코드가 필요하고, ''hostport''는 IP 주소 또는 정규화된 도메인 이름과 포트가 될 수 있다. 보안 전송이 필요한 경우 ''sips'' 스킴이 사용된다.

SIP는 HTTP 요청 및 응답 트랜잭션 모델과 유사하게 설계되었다.^[10] 각 트랜잭션은 클라이언트 요청(서버에서 특정 메서드나 기능을 호출)과 하나 이상의 응답으로 구성된다. SIP는 HTTP의 대부분의 헤더 필드, 인코딩 규칙, 상태 코드를 재사용하여 읽기 쉬운 텍스트 기반 형식을 제공한다.

SIP는 전송 계층 프로토콜인 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP), 스트림 제어 전송 프로토콜(SCTP) 등 여러 프로토콜을 통해 전송될 수 있다.^[11]^[12] SIP 클라이언트는 일반적으로 서버 및 다른 엔드포인트로의 SIP 트래픽에 대해 포트 번호 5060 또는 5061에서 TCP 또는 UDP를 사용한다. 포트 5060은 암호화되지 않은 신호 트래픽에, 포트 5061은 전송 계층 보안(TLS)으로 암호화된 트래픽에 사용된다.

SIP 기반 전화 네트워크는 종종 신호 시스템 7(SS7)의 통화 처리 기능을 구현하지만(이를 위한 SIP 프로토콜 확장이 존재), 두 프로토콜 자체는 매우 다르다. SS7은 중앙 집중식 프로토콜로 복잡한 중앙 네트워크 아키텍처와 단순한 엔드포인트(전통적인 전화 핸드셋)를 특징으로 한다. SIP는 동등한 피어의 클라이언트-서버 프로토콜이며, SIP 기능은 통신하는 엔드포인트에서 구현되는 반면, 전통적인 SS7 아키텍처는 스위칭 센터 간에만 사용된다.

3. 2. 미디어 형식 및 전송 프로토콜

SIP는 미디어 통신 세션의 신호 제어 작업에만 관여하며, 주로 음성 또는 화상 통화를 설정하고 종료하는 데 사용된다. SIP는 2자 통신(유니캐스트) 또는 다자 통신(멀티캐스트) 세션을 설정하는 데 사용될 수 있다. 또한 기존 통화의 수정도 허용한다. 수정은 주소 또는 포트 변경, 더 많은 참가자 초대, 미디어 스트림 추가 또는 삭제를 포함할 수 있다. SIP는 인스턴트 메시징과 같은 메시징 애플리케이션, 이벤트 구독 및 알림에도 적용되고 있다.^[2]

통화 설정을 위해 SIP 메시지의 본문에는 세션 설명 프로토콜(SDP) 데이터 단위가 포함되어 있으며, 이는 미디어 형식, 코덱 및 미디어 통신 프로토콜을 지정한다. 음성 및 화상 미디어 스트림은 일반적으로 실시간 전송 프로토콜(RTP) 또는 보안 실시간 전송 프로토콜(SRTP)을 사용하여 터미널 간에 전송된다.^[2]^[8]

SIP는 전송 계층 프로토콜인 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP) 및 스트림 제어 전송 프로토콜(SCTP)을 포함한 여러 프로토콜에 의해 전송될 수 있다.^[11]^[12] SIP 클라이언트는 일반적으로 서버 및 다른 엔드포인트로의 SIP 트래픽에 대해 포트 번호 5060 또는 5061에서 TCP 또는 UDP를 사용한다. 포트 5060은 일반적으로 암호화되지 않은 신호 트래픽에 사용되는 반면, 포트 5061은 일반적으로 전송 계층 보안(TLS)으로 암호화된 트래픽에 사용된다.

VoIP의 통신 프로토콜로 SIP를 사용하는 경우, 음성 등 스트리밍 송수신에는 실시간 전송 프로토콜(RTP)/RTP 제어 프로토콜(RTCP), 제어를 수행하는 데이터 송수신 호스트 및 포트 제어에는 세션 설명 프로토콜(SDP)을 사용하는 것이 일반적이다. SIP 메시지 송수신에 사용되는 포트 번호로 표준 5060이 규정되어 있다. SIP 메시지 헤더 내에서 호스트와 함께 기술 가능한 포트 번호가 생략될 경우, 5060을 지정하는 것과 동일한 의미를 가진다.

3. 3. SIP URI

SIP 네트워크의 모든 리소스는 통합 자원 식별자(URI)로 식별된다. URI의 구문은 웹 서비스 및 이메일 주소에서도 사용되는 일반 표준 구문을 따른다.^[9] SIP에 사용되는 URI 스킴은 ''sip''이며, 일반적인 SIP URI는 ''sip:username@domainname'' 또는 ''sip:username@hostport'' 형식을 갖는다. 여기서 ''domainname''은 SIP 도메인에 대한 서버를 찾기 위해 DNS SRV 레코드가 필요하고, ''hostport''는 호스트 및 포트의 IP 주소 또는 정규화된 도메인 이름이 될 수 있다. 보안 전송이 필요한 경우, 스킴 ''sips''가 사용된다.

SIP에서 전화번호에 해당하는 것은 '''SIP URI''' (Uniform Resource Identifier)이며, 이메일 주소와 마찬가지로 이름@도메인 형식을 갖는다 (단, SIP URI임을 나타내기 위해 맨 앞에 `sip:`가 붙는다). SIP URI의 예시는 다음과 같다.

`sip:bob@biloxi.example.com`

SIP URI는 특정 개인이나 단말을 나타내는 것만은 아니다. 여러 개인이나 단말을 하나의 그룹으로 묶어 하나의 SIP URI로 나타낼 수도 있다. 이는 전화번호로 말하면 대표번호를 준비하는 것에 해당한다. 예를 들어, 수신처에 개인을 특정하는 주소가 지정된 경우, 지정된 상대가 고장 등으로 통신 불능 상태이면 연결할 수 없지만, 그룹 주소가 지정된 경우, 해당 그룹 내에 고장난 것이 있더라도 다른 통신 가능한 것을 선택하여 연결할 수 있다.

3. 4. HTTP와의 유사성

SIP는 HTTP 요청 및 응답 트랜잭션 모델과 유사하게 설계되었다.^[10] 각 트랜잭션은 서버에서 특정 메서드 또는 기능을 호출하는 클라이언트 요청과 하나 이상의 응답으로 구성된다. SIP는 HTTP의 대부분의 헤더 필드, 인코딩 규칙 및 상태 코드를 재사용하여 읽기 쉬운 텍스트 기반 형식을 제공한다.

SIP는 HTTP를 바탕으로 만들어졌기 때문에 기본적으로 요청-응답형 프로토콜이며, 요청자(UAC)가 클라이언트이고, 응답자(UAS)가 서버이지만, 양자가 이 두 가지 역할을 모두 수행할 수 있다. HTTP에서는 신뢰성이 높은 TCP를 사용하는 것을 전제로 하지만, SIP에서는 UDP를 기반으로 설계되었다. 그러나 상용 환경에서는 신뢰성을 위해 후에 확장된 TCP가 사용되는 경우가 많다.

SIP는 HTTP 1.1과 유사한 텍스트 기반 메시지 형식을 사용하므로 소프트웨어의 기능 추가 및 확장이 용이하다.

3. 5. 전송 프로토콜

SIP는 전송 계층 프로토콜인 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP), 스트림 제어 전송 프로토콜(SCTP)을 포함한 여러 프로토콜에 의해 전송될 수 있다.^[11]^[12] SIP 클라이언트는 일반적으로 서버 및 다른 엔드포인트로의 SIP 트래픽에 대해 포트 번호 5060 또는 5061에서 TCP 또는 UDP를 사용한다. 포트 5060은 일반적으로 암호화되지 않은 신호 트래픽에 사용되는 반면, 포트 5061은 일반적으로 전송 계층 보안(TLS)으로 암호화된 트래픽에 사용된다.

SIP는 HTTP 요청 및 응답 트랜잭션 모델과 유사한 설계 요소를 사용한다.^[10] 각 트랜잭션은 서버에서 특정 메서드 또는 기능을 호출하는 클라이언트 요청과 하나 이상의 응답으로 구성된다. SIP는 HTTP의 대부분의 헤더 필드, 인코딩 규칙 및 상태 코드를 재사용하여 읽기 쉬운 텍스트 기반 형식을 제공한다.

SIP는 H.323을 대체하는 범용 세션 제어 프로토콜로서, DynamicSoft(당시)의 J. 로젠버그 등을 중심으로 개발되었다. SIP에서 "세션"은 OSI 참조 모델에서 규정하는 제5계층과는 다른 의미로 사용된다. 현재 주요 용도는 전화, 화상 전화나 인스턴트 메시징과 같은 양방향 실시간 통신이다.

HTTP는 하위 프로토콜로서 신뢰성이 높은 전송 제어 프로토콜(TCP)를 사용하는 것을 전제로 하지만, SIP는 사용자 데이터그램 프로토콜(UDP)를 기반으로 설계되었다. 그러나 상용 환경에서는 신뢰성을 위해 후에 확장된 전송 제어 프로토콜(TCP)가 사용되는 경우가 많다. SIP는 보안 및 개인 정보 보호를 위한 기능 확장도 갖추고 있다.

SIP 메시지 송수신에 사용되는 포트 번호로 표준 5060이 규정되어 있다. SIP 메시지 헤더 내에서 호스트와 함께 기술 가능한 포트 번호가 생략될 경우, 5060을 지정하는 것과 동일한 의미를 가진다.

SIP 기반 전화 네트워크는 종종 신호 시스템 7(SS7)의 통화 처리 기능을 구현하며, 이를 위해 특별한 SIP 프로토콜 확장이 존재하지만, 두 프로토콜 자체는 매우 다르다. SS7은 복잡한 중앙 네트워크 아키텍처와 단순한 엔드포인트(전통적인 전화 핸드셋)를 특징으로 하는 중앙 집중식 프로토콜이다. SIP는 동등한 피어의 클라이언트-서버 프로토콜이다. SIP 기능은 통신하는 엔드포인트에서 구현되는 반면, 전통적인 SS7 아키텍처는 스위칭 센터 간에만 사용된다.

4. 네트워크 구성 요소

세션 개시 프로토콜(SIP)을 사용하여 통신하는 네트워크 요소는 'SIP 사용자 에이전트'라고 불린다. 각 '사용자 에이전트'(UA)는 요청 시에는 '사용자 에이전트 클라이언트'(UAC) 기능을, 응답 시에는 '사용자 에이전트 서버'(UAS) 기능을 수행한다. 두 SIP 종단점은 중간 SIP 인프라 없이도 작동 가능하지만, 네트워크 운영, 공공 서비스 및 디렉터리 서비스를 위해 SIP는 몇 가지 네트워크 서버 요소를 정의한다. 이러한 각 서비스 요소는 사용자 에이전트 클라이언트와 서버에서 구현된 클라이언트-서버 모델 내에서 통신한다.^[13]

SIP 서버는 SIP 요청을 처리하는 SIP 엔티티이다. UA끼리는 직접 SIP 메시지를 교환할 수 있지만, 일반적으로 SIP 프록시 서버를 통해 메시지를 교환한다. 이는 SIP 프록시 서버를 거침으로써 SIP URI에서 IP 주소를 찾는 작업(DNS 서버에서 호스트 이름의 IP 주소를 찾는 것과 같은 작업)을 UA가 할 필요가 없어지고, 통신 상대가 이동하는 등 IP 주소가 변화해도 그것을 의식하지 않고 통신할 수 있기 때문이다.

SIP 서버의 기능은 각각 물리적으로 별도로 구성하거나 하나로 통합할 수도 있다.

프록시 서버 (Proxy Server): SIP 메시지의 전송(라우팅)을 수행하는 서버.
리다이렉트 서버 (Redirect Server): SIP 요청의 다음 전송 대상을 해결하고, 그 전송 대상을 응답으로 전송하는 서버.
등록 서버 (Registrar): UA로부터의 메시지를 바탕으로 컨택트 주소(SIP URI와 IP 주소의 쌍)를 위치 서버에 등록하는 서버.
위치 서버 (Location Server): UA가 존재하는 네트워크상의 위치를 관리하는 데이터베이스 관리 서버. SIP URI와 IP 주소의 쌍을 레지스트라로부터 받아서 등록하고, 등록 정보를 바탕으로 SIP 프록시 서버로부터의 질의에 응답한다. 위치 서버의 입출력은 SIP 메시지가 아니다.

기존 교환기의 부가 서비스에서 착신에 자동 응답하여 음성 메시지를 재생하는 기능을 제공하는 서버는 엄밀히 말하면 SIP 서버가 아니라 UA이다. 즉, SIP의 UAS(User Agent Server)의 집합체로 구성되어 있다.

4. 1. 사용자 에이전트 (User Agent)

사용자 에이전트는 SIP 메시지를 주고받고 SIP 세션을 관리하는 논리적 네트워크 종단점이다. 사용자 에이전트는 클라이언트 및 서버 구성 요소를 갖는다. 사용자 에이전트 클라이언트(UAC)는 SIP 요청을 보내고, 사용자 에이전트 서버(UAS)는 요청을 받아 SIP 응답을 반환한다. 웹 브라우저가 클라이언트 역할만 하고 서버 역할을 수행하지 않는 HTTP와 달리, SIP는 두 피어(peer) 모두 두 역할을 구현해야 한다. UAC 및 UAS의 역할은 SIP 트랜잭션 기간 동안만 지속된다.

SIP 전화는 SIP 사용자 에이전트의 클라이언트 및 서버 기능을 구현하고 다이얼, 응답, 거부, 통화 대기 및 통화 전환과 같은 전통적인 전화의 통화 기능을 제공하는 IP 전화이다. SIP 전화는 하드웨어 장치 또는 소프트폰으로 구현될 수 있다. 공급업체가 SIP를 표준 텔레포니 플랫폼으로 구현함에 따라 하드웨어 기반 및 소프트웨어 기반 SIP 전화 간의 차이는 모호해지고, SIP 요소는 스마트폰과 같은 많은 IP 지원 통신 장치의 기본 펌웨어 기능으로 구현된다.

HTTP에서와 마찬가지로 SIP에서 사용자 에이전트는 소프트웨어, 하드웨어 또는 제품 이름에 대한 텍스트 설명을 포함하는 메시지 헤더 필드(''User-Agent'')를 사용하여 자체를 식별할 수 있다. 사용자 에이전트 필드는 요청 메시지로 전송되므로 수신 SIP 서버는 이 정보를 평가하여 장치별 구성 또는 기능 활성화를 수행할 수 있다. SIP 네트워크 요소 운영자는 때때로 이 정보를 고객 계정 포털에 저장하여 SIP 호환성 문제 진단 또는 서비스 상태 표시에 유용할 수 있다.

사용자 에이전트(UA: User Agent)는 SIP 요청을 처리하는 논리적 엔티티로, 다음의 두 가지 요소로 구성된다.

사용자 에이전트 클라이언트(UAC: User Agent Client) - SIP 요청을 생성·송신하고 응답을 수신·처리하는 UA.
사용자 에이전트 서버(UAS: User Agent Server) - SIP 요청을 수신·처리하고 응답을 생성·송신하는 UA.

기존 레거시 전화 시스템에 비유하면, SIP 서버가 교환기의 역할을 하는 것처럼 보인다. 그러나 SIP 서비스의 주도권을 가진 것은 사용자 에이전트(UA)이며, SIP 서버는 UA의 요청에 따라 인증과 전화번호 해결을 수행하는 일종의 대리인(Proxy)이다. 발신측 UA가 서비스를 요청하고, 착신측 UA가 서비스를 제공하는 관계이며, 이는 인터넷의 브라우저와 웹 서버의 관계와 같다. 이러한 기능은 모두 UA가 제공한다. 발신측 기능을 UAC(UA Client), 착신측 기능을 UAS(UA Server)라고 한다. 즉, SIP 전화기는 발신할 때는 클라이언트(UAC)로 동작하고, 착신할 때는 서버(UAS)로 동작한다.

4. 2. 프록시 서버 (Proxy Server)

SIP 메시지의 전송(라우팅)을 수행하는 서버이다. SIP 헤더에 포함된 수신처 주소를 키로 위치 서버에 질의하여 수신처의 IP 주소를 구하고, 이를 바탕으로 메시지의 전송 대상을 결정한다.^[1] 전송 대상은 수신처의 IP 주소이거나, 다른 프록시 서버이다.^[1] 이 메시지 라우팅 방법은 SMTP에 의한 메일 라우팅과 같다.^[1]

프록시 서버는 다른 네트워크 요소들을 대신하여 요청을 수행하기 위한 중간 개체 역할을 하는 UAC (User Agent Client, 사용자 에이전트 클라이언트) 및 UAS (User Agent Server, 사용자 에이전트 서버) 구성 요소를 가진 네트워크 서버이다. 주로 통화 라우팅 역할을 하며, SIP 요청을 목적지에 더 가까운 다른 개체로 보낸다. 또한 사용자가 통화를 할 수 있는지 여부를 결정하는 것과 같은 정책을 시행하는 데 유용하다. 프록시는 요청 메시지의 특정 부분을 해석하고 필요한 경우 전달하기 전에 다시 쓴다.

둘 이상의 목적지로 메시지를 라우팅하는 SIP 프록시 서버를 포킹 프록시라고 한다. SIP 요청의 포킹은 단일 요청에서 여러 대화 세션을 설정한다. 따라서 여러 SIP 엔드포인트 중 하나에서 통화에 응답할 수 있다. 여러 대화 세션을 식별하기 위해 각 대화 세션에는 두 엔드포인트의 기여가 포함된 식별자가 있다.

UA끼리는 직접 SIP 메시지를 교환할 수 있지만, 일반적으로 SIP 서버(SIP 프록시 서버)를 통해 메시지를 교환한다.^[1] 이는 SIP 프록시 서버를 거침으로써 SIP URI에서 IP 주소를 찾는 작업(DNS 서버에서 호스트 이름의 IP 주소를 찾는 것과 같은 작업)을 UA가 할 필요가 없어지고, 통신 상대가 이동하는 등 IP 주소가 변화해도 그것을 의식하지 않고 통신할 수 있기 때문이다.^[1]

4. 3. 리다이렉트 서버 (Redirect Server)

리다이렉트 서버는 수신된 요청에 대해 3xx (리다이렉션) 응답을 생성하여 클라이언트가 대체 URI 집합에 연결하도록 지시하는 사용자 에이전트 서버이다. 리다이렉트 서버는 프록시 서버가 SIP 세션 초대를 외부 도메인으로 리디렉션할 수 있도록 한다.

SIP 서버는 SIP 요청을 처리하는 SIP 엔티티이다. UA끼리는 직접 SIP 메시지를 교환할 수 있지만, 일반적으로 SIP 서버(SIP 프록시 서버)를 통해 메시지를 교환한다. 이는 SIP 프록시 서버를 거침으로써 SIP URI에서 IP 주소를 찾는 작업(DNS 서버에서 호스트 이름의 IP 주소를 찾는 것과 같은 작업)을 UA가 할 필요가 없어지고, 통신 상대가 이동하는 등 IP 주소가 변화해도 그것을 의식하지 않고 통신할 수 있기 때문이다.

SIP 서버의 각 기능은 각각 물리적으로 별도로 구성하거나 하나로 통합할 수도 있다. 리다이렉트 서버는 SIP 요청의 다음 전송 대상을 해결하고, 그 전송 대상을 응답으로 전송하는 서버이다.

4. 4. 등록 서버 (Registrar)

등록 서버는 위치 서비스를 제공하는 SIP 종단점이다.^[1] 사용자 에이전트의 주소 및 기타 매개변수를 기록하기 위해 등록 요청(REGISTER requests)을 수락한다.^[1] 후속 요청 시, 네트워크에서 가능한 통신 상대방을 찾기 위한 필수 수단을 제공한다.^[1] 위치 서비스는 하나 이상의 IP 주소를 등록하는 에이전트의 SIP URI에 연결한다.^[1] 여러 사용자 에이전트가 동일한 URI에 등록할 수 있으며, 결과적으로 등록된 모든 사용자 에이전트가 해당 URI로의 호출을 받게 된다.^[1]

SIP 등록 서버는 논리적 요소이며, 종종 SIP 프록시와 함께 위치한다.^[1] 네트워크 확장성을 개선하기 위해 위치 서비스는 대신 리디렉션 서버와 함께 위치할 수도 있다.^[1]

등록 서버는 UA로부터의 메시지를 바탕으로 컨택트 주소(SIP URI와 IP 주소의 쌍)를 위치 서버에 등록하는 서버이다.^[2] UA가 네트워크에 접속하면, 일정 간격으로 REGISTER 메시지를 송출한다.^[2] REGISTER 메시지는 SIP 프록시 서버를 경유하여 등록 서버로 전송되며, 이를 바탕으로 등록 서버가 위에서 언급된 등록을 수행한다.^[2] 즉, 등록 서버에 대한 입력은 SIP 메시지(REGISTER)이다.^[2]

4. 5. 세션 경계 제어기 (Session Border Controller, SBC)

세션 경계 제어기(SBC)는 사용자 에이전트와 SIP 서버 사이에서 네트워크 토폴로지 숨김 및 NAT(네트워크 주소 변환) 트래버설 지원을 포함한 다양한 유형의 기능을 수행하는 미들박스 역할을 한다. SBC는 독립적으로 설계된 솔루션이며 SIP RFC에 언급되어 있지 않다.^[1]

4. 6. 게이트웨이 (Gateway)

게이트웨이는 SIP 네트워크를 공중 전화망과 같이 다른 프로토콜이나 기술을 사용하는 다른 네트워크에 상호 연결하는 데 사용될 수 있다.

5. SIP 메시지

SIP는 HTTP와 유사한 구문을 가진 텍스트 기반 프로토콜이다. SIP 메시지에는 요청과 응답의 두 가지 유형이 있다.^[17]

요청: 사용자 에이전트 클라이언트(UAC)가 서버(UAS)에 어떠한 처리를 요구하는 것을 메서드라고 한다. 요청의 첫 번째 줄에는 요청의 성격을 정의하는 ''메서드''와 요청을 보낼 위치를 나타내는 Request-URI가 있다.^[17]
응답: 사용자 에이전트 서버(UAS)가 수신된 요청의 결과를 나타내기 위해 전송한다. 응답의 첫 번째 줄에는 ''응답 코드''가 있다.^[17]

5. 1. 요청 (Requests)

요청은 프로토콜의 기능을 시작한다. 사용자 에이전트 클라이언트(UAC)가 서버(UAS)로 전송하며, 트랜잭션의 결과 코드를 반환하고 일반적으로 트랜잭션의 성공, 실패 또는 기타 상태를 나타내는 하나 이상의 SIP 응답으로 답변한다. UAC가 UAS에 어떠한 처리를 요구하는 것을 메서드라고 한다.

SIP 요청
요청 이름	설명	비고
REGISTER	To-헤더 필드에 나열된 URI를 위치 서버에 등록하고 Contact 헤더 필드에 제공된 네트워크 주소와 연결한다.	위치 서비스 구현
INVITE	통화 설정을 위한 대화를 시작한다. 사용자 에이전트 클라이언트가 사용자 에이전트 서버로 전송한다.	확립된 대화 중 전송될 때(재초대) 세션을 수정하며, 통화를 보류 상태로 둘 수 있다.
ACK	INVITE 요청에 대한 최종 응답 수신 확인
BYE	대화 종료 및 통화 종료	대화의 어느 엔드포인트에서도 전송 가능
CANCEL	보류 중인 모든 요청 취소	통화 연결 전 종료 등에 사용
UPDATE	대화 상태 변경 없이 세션 상태 수정
REFER	수신자에게 통화 전송 목적의 요청 발행 요청
PRACK	임시 확인	임시 응답(1xx)에 대한 응답으로 전송
SUBSCRIBE	알림자로부터 이벤트 알림 구독 시작
NOTIFY	구독자에게 새로운 이벤트 알림
PUBLISH	알림 서버에 이벤트 게시
MESSAGE	텍스트 메시지 전달	인스턴트 메시징 애플리케이션에서 사용
INFO	세션 상태를 수정하지 않는 중간 세션 정보 전송	DTMF 중계에 사용
OPTIONS	엔드포인트 기능 쿼리	NAT keepalive 목적으로 사용

INVITE: UA에서 SIP 서버로의 세션 확립 요청, SIP 서버에서 접속 대상 단말까지의 세션 확립 요청에 사용된다.
ACK: INVITE의 최종 응답인 상태 코드 200의 응답, "200 OK"의 수신을 확인하는 데 사용된다.
BYE: 세션 해제 요청에 사용된다.
OPTIONS: 통신 상대의 능력을 문의한다.
REGISTER: UA가 위치 정보 등을 레지스트라에 등록한다.

다음은 SIP 서버를 경유하지 않는 (또는 생략된) Alice와 Bob 간의 통화에 대한 표준 시퀀스이다.

Alice	Bob
INVITE F1
180 Ringing F2
<-----------------------\|
\|
200 OK F3
<-----------------------\|
ACK F4
양방향 RTP 미디어
<======================>\|
\|
BYE F5
<-----------------------\|
200 OK F6
\|

Alice가 ACK 메시지를 전송한 후, Bob으로부터 BYE 메시지를 수신할 때까지 RTP 미디어를 통한 양방향 통신이 계속된다.

SIP 서버를 경유하는 시퀀스의 예는 다음과 같다. 여기에서는 atlanta.com과 biloxi.com에 있는 두 개의 SIP 프록시를 경유하여 Alice와 Bob 간에 메시지를 교환한다. 이러한 프록시는 INVITE 메시지를 수신한 직후 100 Trying 응답을 반환한다는 점을 제외하면 메시지를 중계하기만 한다.

SIP 서버 경유 예시
Alice의 소프트폰	atlanta.com 프록시	biloxi.com 프록시	Bob의 SIP 폰
INVITE F1
--------------->\| INVITE F4
100 Trying F5 \|--------------->\|
<---------------\| 180 Ringing F6 \|
180 Ringing F7 \|<---------------\|
<---------------\| 200 OK F9 \|
200 OK F10 \|<---------------\|
<---------------
<---------------
ACK F12
미디어 세션
<================================================>\|
BYE F13
<-------------------------------------------------\|
200 OK F14

5. 2. 응답 (Responses)

응답은 사용자 에이전트 서버(UAS)가 수신된 요청의 결과를 나타내기 위해 전송한다.^[18] 결과 코드의 숫자 범위에 따라 여러 종류의 응답이 인식된다.

1xx: 임시 응답으로, 요청이 유효하며 처리 중임을 나타낸다.
2xx: 요청이 성공적으로 완료되었음을 나타낸다. INVITE에 대한 응답으로 통화가 설정되었음을 의미한다. 가장 일반적인 코드는 200이며, 이는 무자격 성공 보고서이다.
3xx: 요청 완료를 위해 통화 리디렉션이 필요함을 나타낸다. 새 대상으로 요청을 완료해야 한다.
4xx: 잘못된 요청 구문(코드 400) 등 여러 가지 이유로 서버에서 요청을 완료할 수 없음을 나타낸다.
5xx: 서버 내부 오류(코드 500) 등 서버가 명백히 유효한 요청을 충족하지 못했음을 나타낸다.
6xx: 모든 서버에서 요청을 충족할 수 없음을 나타낸다. 대상에서 통화 거부를 포함한 전역 오류를 의미한다.

다음 그림은 SIP 서버를 경유하지 않는 (또는 생략된) Alice와 Bob 간의 통화에 대한 표준 시퀀스를 보여준다.

Alice	Bob
INVITE F1
180 Ringing F2
←-----------------------

200 OK F3
←-----------------------
ACK F4
양방향 RTP 미디어
↔======================↔

BYE F5
←-----------------------
200 OK F6

Alice가 ACK 메시지를 전송한 후, Bob으로부터 BYE 메시지를 수신할 때까지 RTP 미디어를 통한 양방향 통신이 계속된다 (위 그림의 "양방향 RTP 미디어").

SIP 서버를 경유하는 시퀀스의 예는 다음 그림과 같다. 여기에서는 atlanta.com과 biloxi.com에 있는 두 개의 SIP 프록시를 경유하여 Alice와 Bob 간에 메시지를 교환한다. 이러한 프록시는 INVITE 메시지를 수신한 직후 100 Trying 응답을 반환한다는 점을 제외하면 메시지를 중계하기만 한다.

Alice의 소프트폰	atlanta.com 프록시	biloxi.com 프록시	Bob의 SIP 폰
INVITE F1
--------------→\| INVITE F4
100 Trying F5 \|--------------→\|
	180 Ringing F6 \|
180 Ringing F7 \|←--------------\|
←--------------
200 OK F10 \|←--------------\| 200 OK F9 \|
←--------------
←--------------
ACK F12
미디어 세션
↔================================================↔
BYE F13
←-------------------------------------------------
200 OK F14

6. 트랜잭션

SIP는 참가자 간의 교환을 제어하고 메시지를 안정적으로 전달하기 위해 트랜잭션 메커니즘을 정의한다. 트랜잭션은 다양한 타이머로 제어되는 세션의 상태이다. 클라이언트 트랜잭션은 요청을 보내고 서버 트랜잭션은 하나 이상의 응답으로 해당 요청에 응답한다. 응답에는 '1xx' 형태의 응답 코드를 포함하는 임시 응답과 하나 이상의 최종 응답(2xx – 6xx)이 포함될 수 있다.^[19]

트랜잭션은 '초대' 유형 또는 '비 초대' 유형으로 분류된다. 초대 트랜잭션은 SIP에서 '대화'라고 하는 장기간 실행되는 대화를 설정할 수 있다는 점에서 다르며, 따라서 실패하지 않는 모든 최종 응답(예: '200 OK')에 대한 승인(ACK)을 포함한다.^[19]

7. 인스턴트 메시징 및 프레즌스

세션 개시 프로토콜-인스턴트 메시징 및 현황 정보 활용 확장(SIMPLE)은 인스턴트 메시징과 현황 정보를 위한 SIP 기반 표준 모음이다. 메시지 세션 중계 프로토콜(MSRP)은 인스턴트 메시지 세션 및 파일 전송을 허용한다.

8. 상호 운용성 및 적합성 테스트

SIP 개발자 커뮤니티는 SIP 포럼에서 주최하는 컨퍼런스에서 정기적으로 만나 SIP 구현의 상호 운용성을 테스트한다.^[20] ETSI(STF 196)의 태스크 포스에서 개발한 TTCN-3 테스트 명세 언어가 SIP 구현의 적합성 테스트를 명세하는 데 사용된다.^[21]

9. 성능 테스트

SIP 소프트웨어를 개발하거나 새로운 SIP 인프라를 구축할 때, 서버와 IP 네트워크가 특정 통화 부하(동시 통화 수와 초당 통화 수)를 처리할 수 있는지 테스트하는 것이 중요하다. SIP 성능 테스트 소프트웨어는 서버와 IP 네트워크가 통화 부하에서 안정적인지 확인하기 위해 SIP 및 RTP 트래픽을 시뮬레이션하는 데 사용된다.^[22] 이 소프트웨어는 응답 지연, 응답/발신율, RTP 지터 및 패킷 손실, 왕복 지연 시간과 같은 성능 지표를 측정한다.

10. 응용 분야

SIP는 실시간 멀티미디어 데이터 통신 프로토콜인 H.323과 비교했을 때 다음과 같은 특징을 가진다.

세션의 시작, 변경, 종료만 수행하므로 단순하다.
HTTP 1.1과 유사한 텍스트 기반 메시지 형식을 사용하므로 소프트웨어의 기능 추가 및 확장이 용이하다.
인터넷 아키텍처에서 전화 등 세션을 제어하기 위한 프로토콜이다. 기존 전화 제어는 네트워크 중심에 있는 교환기에 의한 집중 제어 방식으로 구현되어 있어, 단말 측에서 쉽게 서비스를 추가할 수 없었다. 이에 반해 인터넷 아키텍처에서는 네트워크는 정보를 전달하는 역할에 집중하고, 단말 측에서 서비스를 임의로 추가할 수 있는 아키텍처이다. SIP로 전화 시스템을 구축함으로써, 인터넷과 마찬가지로 사용자가 단말 측에서 자유롭게 전화 서비스 (영상 포함)를 추가할 수 있게 된다. 참고로 H.323은 IP를 통해 전화, 영상 등의 접속 제어를 수행하는 규약이지만, 집중 제어형 신호 방식이므로 기존 교환기 아키텍처와 동일하다.
VoIP의 통신 프로토콜로 SIP를 사용하는 경우, 음성 등 스트리밍 송수신에는 RTP/RTCP, 제어를 수행하는 데이터 송수신 호스트 및 포트 제어에는 SDP을 사용하는 것이 일반적이다.
SIP 메시지 송수신에 사용되는 포트 번호로 표준 5060이 규정되어 있다. SIP 메시지 헤더 내에서 호스트와 함께 기술 가능한 포트 번호가 생략될 경우, 5060을 지정하는 것과 동일한 의미를 가진다.

10. 1. SIP 연결 및 트렁킹

인터넷 전화 서비스 제공자(ITSP)가 제공하는 인터넷 프로토콜 음성(VoIP) 서비스에 대한 마케팅 용어인 ''SIP 연결''은 고객의 사설 구내 교환기(PBX) 전화 시스템에서 PSTN으로의 전화 통화 라우팅을 제공한다. 이러한 서비스는 음성 및 데이터에 대한 인터넷 접속을 공유하고 기본 속도 인터페이스(BRI) 또는 1차 속도 인터페이스(PRI) 전화 회선에 대한 비용을 제거하여 기업 정보 시스템 인프라를 단순화할 수 있다.^[23]^[24]

SIP 트렁킹은 서비스가 음성, 데이터 및 인터넷 트래픽에 대한 통신사 액세스 회선을 공유하고 PRI 회선에 대한 필요성을 제거하여 통신 인프라를 단순화하는 데 사용될 때 선호되는 유사한 마케팅 용어이다.

SIP 지원 비디오 감시 카메라는 보호 구역에서 물체의 움직임과 같은 이벤트를 운영자에게 알리기 위해 통화를 시작할 수 있다.

SIP는 IP 기반 오디오에서 방송 애플리케이션에 사용되며, 여기서는 서로 다른 제조업체의 오디오 인터페이스가 서로 연결할 수 있는 상호 운용 가능한 수단을 제공한다.^[25]

10. 2. 비디오 감시

SIP 지원 비디오 감시 카메라는 보호 구역에서 물체의 움직임과 같은 이벤트가 발생했을 때 운영자에게 알리기 위해 통화를 시작할 수 있다.

10. 3. IP 기반 오디오

SIP는 IP 기반 오디오에서 방송 애플리케이션에 사용되며, 여기서는 서로 다른 제조업체의 오디오 인터페이스가 서로 연결할 수 있는 상호 운용 가능한 수단을 제공한다.^[25]

11. 구현

미국 국립 표준 기술 연구소(NIST)의 첨단 네트워킹 기술 부서에서는 표준에 대한 참조 구현 역할을 하는 공개 도메인 자바 구현^[26]을 제공한다. 이 구현은 프록시 서버 또는 사용자 에이전트 시나리오에서 작동할 수 있으며 수많은 상업 및 연구 프로젝트에 사용되었다. 3261을 완벽하게 지원하며, 6665(이벤트 알림) 및 3262(신뢰할 수 있는 임시 응답)를 포함한 여러 확장 RFC를 지원한다.

수많은 다른 상업용 및 오픈 소스 SIP 구현이 존재한다. SIP 소프트웨어 목록을 참조하라.

12. SIP-ISUP 상호 연동

ISUP를 캡슐화한 SIP-I(Session Initiation Protocol with encapsulated ISUP)는 SIP 및 IP 네트워크를 사용하여 ISUP 기반 통신 세션을 생성, 수정 및 종료하는 데 사용되는 프로토콜이다. SIP-I를 사용하는 서비스에는 음성, 화상 전화, 팩스 및 데이터가 포함된다. SIP-I와 SIP-T^[27]는 유사한 기능을 가진 두 가지 프로토콜로, 특히 ISUP 메시지를 SIP 네트워크를 통해 전송할 수 있게 해준다. 이는 ISUP 헤더에서 사용 가능한 모든 세부 정보를 보존한다. SIP-I는 ITU-T에서 정의되었고, SIP-T는 IETF에서 정의되었다.^[28]

13. 암호화

공개 인터넷을 통한 통화의 보안에 대한 우려는 안전한 전송을 위해 SIP 프로토콜을 암호화함으로써 해결되었다. URI 체계 SIPS는 SIP 통신을 전송 계층 보안(TLS)으로 보호하기 위해 사용된다. SIPS URI는 sips:user@example.com 형식을 사용한다.

SIP의 종단 간 암호화는 통신 종단점 사이에 직접 연결이 있는 경우에만 가능하다. 직접 연결은 P2P SIP 또는 종단점 간의 VPN을 통해 이루어질 수 있지만, 대부분의 SIP 통신에는 여러 홉이 포함되며, 첫 번째 홉은 사용자 에이전트에서 사용자의 ITSP로 이루어진다. 여러 홉의 경우, SIPS는 첫 번째 홉만 보호하며, 나머지 홉은 일반적으로 TLS로 보호되지 않아 SIP 통신이 안전하지 않다. 반면에, HTTPS 프로토콜은 직접 연결을 사용하고 홉의 개념이 없기 때문에 종단 간 보안을 제공한다.

SIPS 신호 스트림과 별도의 연결인 미디어 스트림 (오디오 및 비디오)은 SRTP를 사용하여 암호화할 수 있다. SRTP에 대한 키 교환은 SDES 또는 ZRTP를 사용하여 수행된다. SDES를 사용하는 경우, SIPS를 사용하지 않으면 키가 안전하지 않은 SIP를 통해 전송된다. 또한 MIKEY 교환을 SIP에 추가하여 SRTP에 사용할 세션 키를 결정할 수도 있다.

참조

_[1] 웹사이트 4G {{!}} ShareTechnote https://www.sharetec[...] 2023-03-09
_[2] 서적 SIP: Understanding the Session Initiation Protocol Artech House
_[3] 웹사이트 SIP core working group charter http://www.ietf.org/[...] Internet Engineering Task Force 2011-01-11
_[4] 웹사이트 Search Internet-Drafts and RFCs https://datatracker.[...] Internet Engineering Task Force
_[5] 웹사이트 What is SIP? https://web.archive.[...] Network World 2004-05-11
_[6] IETF SIP: Session Initiation Protocol
_[7] 웹사이트 Session Initiation Protocol (SIP) http://searchunified[...] TechTarget
_[8] 서적 Telecom 101 Teracom Training Institute
_[9] IETF Uniform Resource Identifiers (URI): Generic Syntax 2005
_[10] 웹사이트 SIP: Session Initiation Protocol https://www.ietf.org[...]
_[11] IETF The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) 2005
_[12] 간행물 Overload mitigation mechanism for VoIP networks: a transport layer approach based on resource management 2016-06-01
_[13] 간행물 OpenSIP: Toward Software-Defined SIP Networking 2018-03
_[14] 서적 Handbook of algorithms for wireless networking and mobile computing https://books.google[...] CRC Press
_[15] 서적 Practical VoIP Security https://books.google[...] Syngress
_[16] 웹사이트 User-Agents We Have Known http://www.voipuser.[...] VoIP User
_[17] 문서 Stallings, p.214
_[18] 문서 Stallings, pp.216-217
_[19] 웹사이트 SIP - An Introduction http://www.konnetic.[...] Konnetic 2011-01-11
_[20] 웹사이트 SIPit Wiki http://www.sipit.net[...] 2017-10-07
_[21] 문서 Experiences of Using TTCN-3 for Testing SIP and also OSP http://portal.etsi.o[...]
_[22] 웹사이트 Performance and Stress Testing of SIP Servers, Clients and IP Networks http://startrinity.c[...] StarTrinity 2016-08-13
_[23] 웹사이트 AT&T Discusses Its SIP Peering Architecture http://sip-trunking.[...] 2017-03-20
_[24] 웹사이트 From IIT VoIP Conference & Expo: AT&T SIP transport PowerPoint slides http://hdvoicenews.c[...] 2017-03-20
_[25] 웹사이트 Streaming audio contributions over IP http://tech.ebu.ch/w[...] 2010-12-27
_[26] 웹사이트 JAIN SIP project https://github.com/u[...] 2024-06-24
_[27] IETF SIP-T Context and Architectures 2002-09
_[28] 웹사이트 Why SIP-I? A Switching Core Protocol Recommendation https://web.archive.[...]
_[29] 뉴스 <알아봅시다> 모바일인터넷전화(mVoIP) http://www.dt.co.kr/[...]
_[30] 웹인용 SIP core working group charter http://www.ietf.org/[...] 2010-11-23

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com