[SIP 개요]
[SIP 특성]
[SIP 기반 네트워크]
- SIP 단말 : 전화기, 이종 망에 대한 게이트웨이(SS7 지원하는 VoIP GW, SSW)
- SIP 서버 : 필요한 부분에 대해서만 SIP 서버를 사용하며 전적으로 SIP 서버를 의존하지 않는다.
SIP 단말은 수신자의 정확한 주소 정보가 없어도 오로지 invite 메시지만으로 호 설정 가능(sip 서버 사용)
SIP 서버는 필요 시 수신자의 다른 단말로 경로 변경 가능(FORKING),
[SIP 기본 특징]
- 주소 지정 방식 : URI, URL 모두 사용, Email 형식, E.164 형식
- 사용자 등록 : 단말은 원활한 호 설정을 위해 서버에 등록된다. 한 사용자가 여러 PC에서 동일한 서비스 사용 가능.
전화망에서처럼 교환기에 의해 미리 설정된 경로를 통해서만 서비스가 이루어지는 것과 대조적
- 보안
- 수신 대체(Redirect) : SIP 서버는 단말의 서비스 요청을 다른 서버에 대체할 수 있다. 지능망(AIN)의 해당 기능과 유사
- Proxy : SIP Proxy Server 는 특정 서비스를 요청하는 경우 해당 서비스를 제공 할 수 있는 다른 서버로 그 요청을 전달
- Forking : 등록 단말이 여럿인 경우 요청을 상대방의 여러 단말로 동시에 전달
- 상태정보와 랑데부(Rendezvous) : 랑데부의 동적 형태는 필요한 서비스를 제공할 수 있는 서버나 단말로 호 설정을
직접 요청하는 것으로 구성된다. 반면 수동 형태에서는 상태정보로 구성된다. 즉 단말에서 어떠한 서비스를 필요로
한다는 것을 상태정보 등록을 통해 상대방이 알도록 한다.
- 이동성 : 다양한 통신 단말과 다양한 망 사용(IP망, 전화망, 이동통신망, Wibro망, WiMAX 등)
- 사용자 취향(User Preferences) : 발신자는 자신의 요청이 서버나 망에서 어떻게 처리될지를 정할 수 있다.
통화 가능은 물론 원치않는 상대방 그룹을 미리 지정할 수 있고, 상대방이 통화중이거나 자동응답기이면 아예
연결되지 않도록 설정할 수도 있다. 수신자 입장에서도 발신자가 누구인지, 어디에서건 전화인지, 통화 시간대,
단말 종류 등 다양한 기준에 따라 수신 여부를 능동적으로 결정할 수 있다.
- 경로 제어 : SIP 메시지의 전달 경로 또한 제어되거나 저장할 수 있다.
=> 이런 대부분의 기능들이 지능망(AIN)이나 웹, 이메일에서 사용되지만 기존 전화망에서는 제공되지 않는 SIP만의
기능들이다.
* 랑데부(클라이언트와 서버, 서버와 서버간 메시지 전달 프로토콜, RVP라고 함. draft-calsyn-rvp.txt 참고)
[표준 제정 과정의 투명성]
- 개방성 : 열린 개발 과정 표준화 제안, 방대한 표준 문서
- 자발적 기여
- 넘쳐나는 창의성
- 실행 코드에 근거한 SIP 표준화 : 표준 확정 되기전에 기능 구현을 통해 검증
[SIP 범위]
SIP는 양방향 세션의 시작, 수정, 종료에 관한 프로토콜이다. SIP는 장치 제어나 원격 프로시저 호출(RPC)를 위한
프로토콜은 아니다. 그렇다고 전송 프로토콜도 아니다. 메시지가 첨부되기도 하지만 대용량 데이터나 스트림 전송에
사용할 수는 없다. SIP 메시지가 설정한 전송 경로가 뒤에 따라오는 미디어의 전송 경로를 보장하는 것은 아니기 때문에
자원 예약(RSVP) 프로토콜도 아니다. SIP는 PSTN을 대체하는 프로토콜도 아니다. SIP의 틀은 전화의 시그널링 프로토콜
이나 통화 모델과 근본적으로 다르다. 물론 GW를 통해서 PSTN과 상호 연동할 수 있지만 그렇다고 SIP의 기본 역활이라
할 수 없다. SIP는 세션 관리 프로토콜이 아니라 세션 설정 프로토콜이다.
SIP는 VoIP 프로토콜도 아니다. VoIP는 SIP 네트워크에서 제공 될 수 있는 여러 서비스 가운데 하나일 뿐이다. SIP는
오로지 시그널링 프로토콜로써 미디어에 관한 사항, 즉 미디어 타입, 종류, 서비스 등에 대해서는 전혀 규정하지 않는다.
반면 H323은 그 이전의 ISDN 처럼 시그널링은 물론 미디어, 호 기능, 서비스, 세션 제어 등 모든 사항이 포함되어 있다.
[SIP 소개]
http와 smtp 를 바탕, 기본 목적은 세션 설정(Initiation)이다. 메시징 presence 기능 제공도 포함.
SIP는 P2P 프로토콜로써 세션에 참여하는 상대는 서로 대등한 관계지만 http 처럼 서버-클라이언트 트랜잭션 모델을
사용한다. SIP 클라이언트는 SIP Request 를 요청하고, SIP 서버는 응답 메시지를 통해 클라이언트의 요청에 응답한다.
SIP 메소드 : invite, ack, bye, cancel, register, options, info, prack, update, refer, subscribe, notify, message, publish
SIP 응답 코드 : 1xx, 2xx, 3xx, 4xx, 5xx, 6xx
------------SIP 메시지의 행별 설명------------
|
행 |
설명 |
|
INVITE sip:userb@there.com SIP/2.0 |
SIP 요청 메시지의 첫줄은 다른 헤더를 포함하지 않는다. 메소드(여기서는 invite) 이름으로 시작하여 한 칸 띄고 요청의 목적지 주소인 Request-URI(여기서는 sip:userb@there.com)가 오며 다시 한 칸 띄고 SIP의 버전(2.0)이 온다. 모든 행은 CRLF(carriage Return and Line Feed)문자로 끝난다. SIP 버전은 RFC 2543이나 RFC 3261 모두 2.0이다 |
|
Via: SIP/2.0/UDP 4.3.2.1:5060 ; branch=z9hG4bk765d |
Via헤더는 SIP 버전(2.0), 전송 프로토콜(UDP), 발신자의 IP주소 또는 호스트 이름, 포트 번호로 구성된다. Proxy 서버는 자신의 주소와 포트 번호를 새로운 Via 헤더 로 추가함으로써 향후의 응답 메시지들을 해당 주소로 받을 수 있다. branch 는 트랜잭션 구분자로써 앞의 7개 문자로 구성되는 쿠기(z9hG4bk) 할당. |
|
To: User B <sip:userb@there.com> |
To 헤더는 수신자의 이름과 <> 안에 표시되는 수신자 URI 로 구성된다. |
|
From: User A <sip:usera@there.com> |
From 헤더는 Request 요청자의 이름과 <> 안에 표시되는 요청자의 URI 담음. |
|
Call-ID: 4r59899D8g19c3414 tag=34kd92kfs |
Call-ID 헤더는 해당 호, 즉 세션에 대한 식별자(난수). 같은 세션의 모든 요청 및 응답 메시지는 동일한 Call-ID를 갖는다. |
|
Max-Forwards: 70 |
홉 수이며 Proxy 서버를 한 번 거칠 때마다 1씩 감소한다. '0' 되면 "483 Too Many Hops" 응답 메시지가 보내진다. |
|
CSeq: 1 INVITE |
CSeq는 메시지 순서로써 번호(여기서는 1)와 현재 메소드이름(여기는 INVITE) 으로 구성. 송신측과 수신측은 서로 독립적으로 개별 순서를 갖는 CSeq 사용. |
|
Contact: sip:usera@4.3.2.1 |
Contact 헤더는 발신자 자신(User A)의 연락 가능한 하나 이상의 연락처 담음. |
|
Content-Length: 126 |
메시지 본문의 byte 수. 본문은 SIP 헤더를 뒤에 나타나며 그 수에 SIP 헤더들은 포함되지 않는다. Content-Length 가 '0' 이면 본문이 없는 메시지이다. |
[SIP 네트워크 구성 요소]
유저 에이전트 : SIP UA는 http 와 달리 SIP UA가 서버도 되고 클라이언트도 된다.
서버(RFC3261) : Proxy, Redirect, Registrar
- Outbound Proxy : UAC가 invite를 보낼 때 경유하는 Proxy 서버
- Incoming Proxy : SIP URI에 포함된 domain 주소로부터 해당 domain 의 Proxy 서버 IP가 추출된다.
이 경우 Proxy 서버는 걸려오는 호를 해당 도메인으로 유도하는 데 사용되기 때문에 Incoming Proxy 로 불린다.
SIP Registrar 서버는 UA에 수동 설정하거나 IP 멀티캐스팅을 통해 접근 될 수 있다.
또 UA는 자신의 1차 Proxy 서버에 등록 메시지를 보낼 수 있는데, Proxy 서버가 등록 요청을 Registrar 서버로 전달한다.
위치지정 서비스(Location Service)는 곧 DB라 할 수 있다. DB에는 URI, IP주소, Script, 사용자 취향 등 사용자 정보,
SIP 네트워크 라우팅 정보도 포함 된다.
[SIP 기능들]
주소 결정, 세션 관련 기능들, 호 중간 시그널링, 호 제어, QoS 호 설정, 세션 외 기능
[주소 결정]
Addrss Resolution 은 SIP 의 중요 기능. SIP주소 결정은 보통 URI로 시작하여 IP주소와 사용자명을 파악 하는 것.
주소 결정은 UA, Server 모두 수행 가능.
주소 결정 과정 절차
- DNS NAPTR 문의 : RFC 3263에 의거, 전송 프로토콜을(TCP, UDP, SCTP) 결정
- DNS SRV 문의 : RFC 3263에 의거, 서버 호스트 이름과 포트 번호를 결정
- DNS 문의 : 호스트의 IP 주소를 결정
- ENUM 문의 : 전화번호라면 그 번호를 찾음
- 위치지정 서비스 문의 : 주소 문의가 Proxy 서버로 미뤄질 때에는 RFC 3261 에 의거, 위치지정 서비스를 참조
주소 결정 과정의 request 메시지는 UA나 Proxy 의 Hop 별로 DNS나 라우팅 테이블에 문의하여 목적지 까지 전달된다.
반면 response 는 역으로 보내기 때문에(Via 헤더 기록 참고) 주소 결정 과정이 필요 없다.
SIP의 주소 결정 절차는 dynamic 하다. Proxy 는 request 메시지 내의 여러 정보와 다양한 헤더를 경로 설정에 할용
(timestamp 시간정보, From 헤더, 자동 호 분배 ACD 나 부하 분산을 위한 여러 헤더)
이런 주소 결정 과정은 세션 시작 시점에 단 한번만 수행된다. 한번 파악된 주소들은 저장되어 이후 메시지 전송 시 사용.
[* IP의 SIP 메시지 전송]
IP-TCP(TLS SSL), UDP(Datagram TLS-DTLS, 일반), SCTP 를 통해 전달.
SIP는 자체 신뢰 보장 체계를 가지고 있어서 UDP 처럼 보장 체계가 없는 'best effort' 전송 프로토콜도 사용 가능.
하나의 SIP 메시지가 여러 hop 으로 전달 되는 경우 각각의 홉 구간은 UDP or TCP가 될 수 있다. 사용된 전송 프로토콜은
메시지 IP 주소 및 Port 번호와 함께 Via 헤더에 기록된다.
UDP는 SIP 전화기 처럼 간단한 User Agent 가 주로 사용
TCP는 Proxy 서버 간, 또는 장시간 연결이 필요한 경우 주로 사용
SCTP 는 대용량의 트래픽 처리와 낮은 지연시간을 요하는 대용량 PSTN GW와 Proxy 간 연결 설정의 위해 주로 사용.
[세션 관련 기능들]
[세션 설정]
UAC는 세션을 시작하면서 (To,From,Call-ID) 헤더를 설정하는데, 이 3가지 정보를 "dialog" 라고 부르며 하나 세션 구분.
한 세션 동안 변경 되지 않는다. 이 정보와 기타 미디어 정보를 추가한 것을 '호 상태' 라고 하며 UAC는 반드시 이 호 상태
를 기억하고 있어야 한다. ( UAS는 UAC의 Call-ID, UAC의 To 값을=>From, UCA의 From 값을=>To 사용한다 )
인터넷 철학이 그러하듯 SIP 호 상태는 네트워크 내부가 아닌 SIP 단말에서 유지된다. 물론 SIP Proxy 서버도 세션 설정
과정을 기록 할 수 있지만 SIP 호 상태를 단말이 기억하게 함으로써 호 설정을 망에 독립적으로 관리할 수 있다.
성공 : INVITE/200/ACK
실패 : INVITE/4xx, 5xx 또는 6XX/ACK
INVITE는 ACK를 동반하는 유일한 메시지. 나머지 요청의 메시지들은 Request/200, Request/4xx, 5xx , 6xx 로 응답 한다.
설정과정에서 100, 180 진행 응답(1xx, provisional message)메시지가 있을 수 있다.
호 성립 되면 더 이상의 SIP signal 메시지 없이 미디어 세션이 진행된다. 그러나 'SIP Session Timer' 를 사용하면
일정 시간 이후 미디어 세션의 종료, 즉 통화시간을 제한할 수 있다. 세션 성립 과정 중에 forking 기능 가능
[미디어 협상]
SIP 자체로 media 협상 지원 하지 않기 때문에 협상은 SDP 를 통해 이루어진다.
INVITE(with SDP)/200ok(응답) or INVITE/200ok(SDP)/ACK(응답) -> RFC 4317(SDP 제안/응답 모델)
추가적인 media 협상은 re-INVITE 메시지를 통해 가능.
하지만 SDP를 이용한 media 협상은 다소 제한적일 수 밖에 없어 SDPng 로 불리는 SDP 보안할 새로운 표준 검토 중
------------SDP 제안 예------------
|
항목 |
내용 |
|
v=0 |
Version - SDP의 현재 버전(0) - SIP 사용 안함 |
|
o=usera 2890844526 2890844526 IN IP4 client.example.com |
Origin - SIP에서는 버전번호(2890844526)만 사용 |
|
s=Subject |
제목 |
|
c=IN IP4 128.2.3.1 |
Connection - 네트워크(IN은 인터넷 나타냄), 주소 형식 (IPv4는 IP version 4를 나타냄), IP 주소(128.2.3.1) |
|
t=0 0 |
Time - 시작 시간과 종료 시각 - SIP 사용 안함 |
|
m=video 51327 RTP/AVP 34 98 |
Media - 미디어 형식(Video), 포트 번호(51372), 형식(RTP/AVP profile), profile 번호(34 or 98) |
|
a=rtpmap:34 H263/90000 |
Attribute - rtpmap 으로 RTP/AVP profile 34의 규격 나열 : 코덱(H.263), 샘플링 주기(90000Hz) |
|
a=rtpmap:98 H264/90000 |
Attribute - rtpmap 으로 RTP/AVP profile 98의 규격 나열 : 코덱(H.264), 샘플링 주기(90000Hz) |
|
m=audio 4006 RTP/AVP 0 97 |
Media - 두번째 미디어 형식(audio), 포트 번호(4006), 형식(RTP/AVP profile), 프로파일 번호(0 or 97) |
|
a=rtpmap:0 PCMU/8000 |
Attribute - rtpmap 으로 RTP/AVP audio profile 0의 규격 나열 : 코덱(PCMU: PCM u-law), 샘플링 주기(8000Hz) |
------------SDP 응답 예------------
|
항목 |
내용 |
|
v=0 |
Version - SDP의 현재 버전(0) - SIP 사용 안함 |
|
o=usera 2890844342 2890844543 |
Origin - SIP에서는 사용 안함 |
|
IN IP4 client.example.com |
|
|
s= - |
제목 |
|
c=IN IP4 16.22.33.1 |
Connection - 네트워크(IN은 인터넷 나타냄), 주소 형식 (IPv4는 IP version 4를 나타냄), IP 주소(16.22.33.1) |
|
t=0 0 |
Time - 시작 시간과 종료 시각 - SIP 사용 안함 |
|
m=video 0 RTP/AVP 34 98 |
Media - 미디어 형식(Video), 포트 번호(0)은 해당 미디어 세션 거절을 의미 |
|
m=audio 6002 RTP/AVP 97 |
Media - 두번째 미디어 형식(audio), 포트 번호(6002), 형식(RTP/AVP profile), 포트번호 (0)이 아니면 해당 미디어 세션을 수용 |
|
a=rtpmap:97 iLBC/8000 |
Attribute - rtpmap 으로 RTP/AVP audio profile 97의 규격 나열 : 코덱(iLBC), 샘플링 주기(8000Hz) |
[세션 변경]
세션은 INVITE/200/ACK 과정을 통해 설정. 세션 변경은 re-INVITE/200/ACk 과정으로 이루어 진다.
세션 당사자 어느 쪽에서든 요청될 수 있다. 이전 INVITE와 동일한 To, From, Call-ID 를 사용한다.
re-INVITE가 거절되어도 기존 미디어 세션에는 아무런 영향을 끼치기 않는다.
re-INVITE가 수락되면 기존 미디어 세션은 새로운 미디어 세션으로 대체된다.(새로운 SDP의 내용 수정 가능)
[세션 종료BYE 및 취소CANCEL]
CANCEL 은 INVITE 후 최종 응답 메시지(2xx,3xx,4xx,5xx,6xx)를 받기 전에 CANCEL 메시지를 보내는 경우.
Forking 과정에서 Proxy 가 여러 수신 단말에 동시에 CANCEL 을 보내 호 취소를 한다.
INVITE와 BYE는 단말 대 단말 메소드인 반면 CANCEL은 홉 단위 메소드이다. CANCEL을 받은 Proxy 는
200ok 응답을 보내고, 해당 INVITE를 보냈던 원래 목적지에 CANCEL 메시지를 전달.
CANCEL 을 받은 UA는 해당 INVITE에 대한 최종 응답 메시지를 아직 보내지 않았다면 200ok 를 보내고
이어서 486 Request Cancelled 로 정상 호 취소 상태가 된다
하지만 이미 INVITE에 대한 응답 메시지를 보낸 후라면 481 Transaction Unknown 메시지로 응답한다.
[통화중 시그널링]
통화중 시그널링(Mid-call signaling)이란 두 UA 사이에 설정된 현재 세션 파라미터를 변경하지 않는 시그널링 메시지의
교환을 의미. 만약 현재 세션 파라미터를 변경한다면 re-INVITE를 사용한다. 그 외의 경우 SIP INFO 메소드가 사용.
즉 교환 정보는 INFO 의 메시지의 본문으로 전달된다. ISUP(ISDN User Part)망의 경우, ISDN USR(User to User Message)
에 포함된 통화중 시그널링 정보는 INFO 메소드를 통해 전송된다.
[호 제어]
SIP는 BYE는 단대단으로 이루어 진다. 하지만 두 UA간 호 제어 및 관리를 제3자가 하면 훨씬 다양한 서비스 가능.
제3자가 호 제어 구현 방법 2가지. 첫번째 제어기가 발신자의 SIP INVITE 요청에 중간에 직접 응답하고 원래 수신자를
제3자로 INVITE 하는 방식이다. 제어기는 발신자와 제 3자간 시그널링의 중간에 위치하며 SDP를 중계하는 등
드러나지 않게 호를 제어할 수 있다.(결국, MiTM 같은 원리 인가 보다) 두번째는 REFER 메소드를 사용하는 방법.
A와 B가 세션을 설정하고, REFER 요청을 통해 B로 하여금 C와 호를 맺도록 하는 예.
REFER를 이용한 호 제어 예
아래는 Originator<-->Recipient 통화 중 Originator 이 콜 트랜스퍼 해서 Recipient<-->Final-recipient 통화
또는 Click to call 에서 활용
user1@sip 계정 권한을 가진 유저가 웹(또는 프로그램에서)에서 user2@sip 로 전화 걸게 되면
Web Server 가 Invite 를 자신의 user1@sip 로 보내어 전화를 걸게 됩니다. 이후 REFER 를 보내어
user1@sip 이 user2@sip 와 통신을 하게끔 합니다. 이후 Web Server 가 BYE를 보내게 되고
user1@sip 는 user2@sip 로 전화를 걸게 됩니다.
http://level7systems.co.uk/en/blog/Click+to+Call+with+PHP-SIP
REFER 의 메시지의 Refer-TO 헤더는 A가 호를 설정해야 할 상대방의 URI를 나타내고 Referred-By 헤더는 호 설정을
요청하는 제3자인 자신을 나타낸다. Referred-By 헤더는 B의 INVITE 메시지에도 포함되어 C로 하여금 호를 요청한
주체가 누구인지 알 수 있게 한다.
[호 설정 전제 조건]
SIP 확장 부분에서 QoS 알아보자. re-INVITE 를 이용할 수 있다. 먼저 'best-effort' 철학에 근거하여 세션을 설정 한 후,
조건에 만족되지 않으면 re-INVITE를 통해 세션을 변경하는 것이다. 하지만 SIP 메세지는 미디어로 부터 독립적이므로
새로운 세션의 설정은 기본 세션이 실패하였을 경우, 즉 미디어 전송에 필요한 대역폭의 절대부족으로 세션이 중단되는
경유에 가능하다. 따라서 re-INVITE 방식으로는 원하는 QoS 를 항상 보장할 수 없다. 다른 방법은 PSTN 방식을 따라하는
것으로 수신측에서 판단하기에 세센에 필요한 충분한 대역폭이 준비되어있지 않으면 아예 벨을 울리지 않도록 하는
것이다. 이 방식은 Voice over Cable Modem 프로젝트를 목적으로 하는 PacketCable 컨소시움에서 개발되었있다.
Prack, Update 를 사용하는 Call Flow 로 설명 진행 <- 아쉽게 그림이 없음 --;
세 가지 SIP 확장
1. Early Media 로써 183 Session Progress 진행 메시지에 SDP를 실을 수 있게 확장한 것이다.
이를 통해 두 UA는 호 요청이 응답되기 전에 QoS 관련 협의를 SDP를 통해 서로 주고받을 수 있다.
2. 신뢰성있는 진행 메시지(Reliable Provisional Response)로의 확장으로써 183 응답과 같은 진행메시지가 제대로
전송되지 않았을 경우 이를 발견하여 재전송하도록 한 것이다. 183 응답의 수신을 확인하는 메시지가 바로
PRACK(Provisional Response ACKnowledgement)이다.
3. COMET(preCOnditions MET) 메소드이다. UAS 는 COMET 을 받고 나서 QoS 협의가 수락되었음을 알고 벨을 울린다.
이후는 이랍ㄴ 호 처리과정과 동일하다. 현재는 COMET 대신에 동일한 의미로써 UPDATE 메소드가 사용된다.
위 3가지 확장은 첫 INVITE 메시지의 SDP의 마지막 줄의 qos:mandatory 항목에 의해 유발된다.
a=qos:mandatory
-----------------------------------------------
[SIP의 메시지 재전송]
SIP는 request, response 가 분실되었을 경우 거의 대부분 자동으로 재전송 한다. 발신측이 메시지 전송과 동시에
타이머를 작동시킨다. 이 첫 번째 타이머를 T1이라 하며 초기 설정값은 보통 500ms 이다. 이 시간동안 응답 메시지가
전혀 오지 않으면 원래 요청 메시지를 재전송하고, 타이머 시간내에 진행 메시지(1xx)가 오면 발신측은 보다 긴 타이머인
T2(초기값은 4초)를 작동시킨다. 만약 발신측의 요청 메시지 자체가 분실되었다면 수신측은 요청 메시지를 받지 못할
것이고 응답 메시지 또한 생성하지 않을 것이다. 이 경우에는 수신측 T1 타이머의 시간이 다하게 되고 발신측은 요청
메시지를 재전송한다. 재전송된 요청 메시지를 받은 수신측은 자신이 보낸 응답 메시지가 분실되었음을 알게 되고
그 응답 메시지를 재전송한다.
INVITE 요청 메시지의 경우는 다른 요청 메시지의 경우와 그 처리 방식이 다르다.
INVITE 요청의 최종 응답은 수신측 사용자가 수화기를 들어야만 가능하므로 그 시간이 상대적으로 길다.
따라서 발신측은 INVITE 요청에 대한 진행 응답(Provisional Response)을 수신하더라도 타이머 T2를 작동시키지 않고
대신에 더 이상의 INVITE 요청 메시지 재전송을 중단한다. 수신측에서는 INVITE 메시지를 수신하고 나서 최종 응답
메시지를 전송할 때 비로소 T1 타이머를 작동시킨다. 만약 발신측으로부터 타이머 시간내에 ACK를 보내오지 않으면
그 응답 메시지를 재전송한다. 이러한 절차를 통해 분실된 INVITE나 최종 응답 메시지, 즉 ACK의 확실한 전송을 보장하게
된다. 이와 같은 재전송 규칙의 예외는 진행 메시지이다. 진행 메시지는 ACK를 요구하지 않기 때문에 그 메시지가
분실되었는지 잘 수신되었는지 확인할 방법이 없다. 그래서 PRACK 라는 신뢰성 있는 진행 응답
(Reliable Provisinal Responese) 메시지 확장이 개발되었으며 이를 통해 SIP의 모든 요청 및 응답 메시지에 대한 신뢰성을
보장 할 수 있게 된다.
GK#sh sip-ua timers
SIP UA Timer Values (millisecs unless noted)
trying 500, expires 180000, connect 500, disconnect 500
prack 500, rel1xx 500, notify 500, update 500
refer 500, register 500, info 500, options 500, hold 2880 minutes
tcp/udp aging 5 minutes
-----------------------------------------------
[세션 외 기능들]
[이동성]
SIP의 등록 기능은 이동전화에서의 등록과 유사하다. 사용자는 Proxy로 보내는 등록 메시지에 수신 가능한 URI을 실어
보낸다. 등록 서버(registrar server 는 위치 서버(Location Server)에 있는 사용자 레코드를 갱신하고 등록 확인 메시지인
200ok 응답을 보낸다. 사용자가 사무실을 떠나 집에 도착하면 집전화를 새로 등록하면 사무실 SIP 전화기의 등록은
취소한다. 전화기와 등록서버 간에 SIP를 사용하지만 등록서버와 위치서버는 다른 프로토콜을 사용 할 수 있다.
또한 집 전화기도 반드시 SIP단말일 필요는 없고, PSTN 전화기이더라도 웹이나, 이메일, 또는 다른 등록 프로그램을
통해 등록할 수 있다.
다수의 URI를 함께 등록할 수 있으며 선호하는 순서로 우선순위가 주어진다.
아래 처럼 우선순위의 3가지 URI를 등록 할 수 있다.
<SIP client to Registrar>
REGISTER
...
Contact: sip:usera@4.3.2.1;class=personal
Contact: tel:+1-314-555-1212
Contact: mailto:usera@here.com
<Registrar to SIP client>
200 OK
...
Contact: sip:usera@4.3.2.1;class=personal
Contact: tel:+1-314-555-1212
Contact: mailto:usera@here.com
Contact 헤더의 SIP URI 에 확장된 파라미터들이 추가될 수 있다. 통화자 취향(Caller Preferences) 표준에서 볼 수 있는
확장 파라미터들은 통해 사용자는 URI 단말에 대한 부가정보를 지정할 수 있다. 즉 첫번째 URI는 개인 URI, 둘째는
음성메일, 셋째는 업무용, 넷째는 이동전화로 지정할 수 있다. 순서대로 호 시도를 하게 된다.
비슷한 예로 Reject-Contact 헤더도 있는데 특정 단말이나 방식으로의 연결은 원치 않음을 지정할 수 있다.
Proxy가 SIP 메시지를 처리할 때, 해당 메시지를 Proxy 방식으로 처리 할 지, 다른 서버로 대처 할 지, 다수 단말을
순차적으로 시도할지 아니면 동시에(forking) 시도할지에 대한 결정은 서버의 재량이다.
하지만 Request-Disposition 헤더를 사용하면 그 처리방식을 발신자가 직접 지정할 수 있다.
예를 들어 Request-Disposition: proxy, sequential 헤더는 해당 호 연결이 대체(redirect) 방식이 아닌 Proxy 방식 방식으로,
수신 단말들을 동시에 시도하지 않고 순차적으로 시도하도록 지정한다. 통화자 취향 표준에 기술되어 있다.
UA는 Requires:prefs 헤더를 추가하여 등록서버가 사용자 취향 정보를 처리하도록 요청할 수 있다.
[메시지 전달]
MESSAGE 메소드는 해당 URI로 메시지를 전달할 때 사용된다. MESSAGE 메소드 전달은 해당 세션의 내외 모두에서
가능하다. URI가 SIP 가 아니라 IM URI를 사용한다. A가 보낸 것을 받으면 B는 200 ok 응답을 보내게 된다.
INFO 메소드는 두 UA 간에 세션이 설정되어 있어야만 전달될 수 있는 반면에 MESSAGE 메소드는 세션 설정에
관계없이 아무 때나 전달될 수 있다.
To: User B <im:userb@there.com>
From: User A <im:uesra@here.com>;tag=4541232ds
[이벤트 알림요청 및 알림]
SUBSCRIBE(알림요청), NOTIFY(알림)는 특정 이벤트에 대한 알림을 요청하고 정보를 제공하는 기능이다.
수신자가 통화중일 때 통화가 끝나는 즉시 발신자에게 전화를 걸어주는 자동 콜백 기능을 들 수 있다.
아래 처럼 A->B로 전화 시 B가 통화 중이면 486으로 통화 중이라는 응답을 받는다.
A는 B에게 통화를 마치면 알려달라는 신호로 Subscribe 메시지를 보내고 B가 통화를 끝낸 후 Notify 메시지를 보내면
A는 세션을 설정한다.
알림요청 메시지의 Event 헤더는 요청하는 이벤트가 무엇인지를 나타낸다 만약 B가 해당 이벤트의 알림을 원치 않을
경우에는 603 Decline 응답으로 거부할 수 있다. Subscribe, Notify 는 서버 없이 구현될 수도 있고, PUBLISH 메소드를
통해 서버를 사용하는 구현도 가능하다.
[상태정보 알림]
SIP PUBLISH 메소드를 통해 UA는 자신의 상태정보를 상태정보 서버에 저장하거나 공개할 수 있다.
상태정보 서버는 저장된 정보를 원하는 사용자들에게 보낸다.
[인증]
두 가지 인증 제공(UA간, UA와 Server간) , 서버와 서버간은 SIP 자체로는 제공하지 않고 다른 프로토콜(ex. IPSec)로 제공.
SIP 인증은 대부분 http 에서 가지고 왔으며 대표적인 예가 SIP Digest 인증 이다. 어떤 SIP 메시지도 인증을 요구 받을 수
있다. SIP와 Proxy 간 인증은 407 응답 사용. 단 Proxy 와 Proxy 간 인증은 없다. 대신 IPSec 등을 사용 한다.
[확장성]
SIP 확장이 쉽다. 기존의 서버나 Proxy 변경 없이 개별 UA들은 메시지 본문이나 새로운 헤더를 이용하여 확장된 기능을
구현할 수 있다. 메시지에 잘 모르는 헤더나 요청이 포함되어 있더라도 수정없이 전달한다. 요청자는 Supported 헤더에
새로운 확장이 포함되어 있다는 정보를 실어 망과 사용자에게 알려주며 이를 어떻게 처리할 지에 대한 안내를 제공한다.
만약 확장된 기능이 반드시 처리되어야 할 사항이라면 Require 헤더를 이용하여 명시한다. 이 메시지를 받은 UA가 추가된
기능에 대해 모르거나 지원할 수 없으면 오류 응답을 보낸다. 또한 Proxy-Require 헤더를 통해 메시지가 전달되는 과정에
위치한 Proxy들이 처리해야 할 확장 기능임을 명시할 수 있다. 하지만 이러한 헤더의 사용은 호 성공률을 낮추고 원활한
상호 연동을 제한할 수 있기 때문에 가급적이면 사용하지 않는 것이 좋다.
또한 UA는 Allow, Supported, Allow-Events 및 Accept-Content 헤더를 통해 자신이 지원 가능한 기능과 메소드들을
분명하게 명시하는 것이 바람직하다.
[출처] [VoIP SIP 알자/6. SIP 개요]|작성자 쏠라구구
