SIP method on RFC 3261

개요

원문은 이곳<ref>http://www.nexpert.net/491</ref>에서 확인할 수 있다.

SIP 호 절차를 이해하기 위해서는 SIP 메시지에 포함된 SIP 헤더를 잘 알아야 한다. SIP 헤더에 대한 기본적인 내용만 알고 있어도 쉽게 호 절차를 분석할 수 있다. 특히, 이기종 장비간 SIP Trunk 연동이나 단말 연동 시 장애가 발생할 경우에 SIP 패킷을 수집하여 분석하는 과정을 거치게 된다. SIP 헤더를 알지 못하면 수집된 패킷은 암호문일 뿐이다.

SIP 주소 체계

PSTN 전화망은 E.164 주소 체계를 사용하고, 인터넷망은 IP 주소 체계를 사용한다. E.164 주소체계는 사람이 인식하기 쉬운 주소 체계이지만, IP 주소체계는 어렵다. 인터넷에서 유투브나 네이버를 접속하기 위해 IP 주소를 웹브라우저에 입력하여 접속할 수 있지만, 사람들은 도메인 네임인 http://www.youtube.com 이나 http://google.com 이라는 도메인 네임으로 접속한다. IP 주소 체계보다 도메인 네임 체계가 훨씬 이해하기 쉽기 때문이다. 전자메일도 마찬가지이다.

SIP를 이용한 통화를 위한 주소체계는 다양한 방식의 주소 방식을 지원한다.

• FQDN(Fully-Qualified Domain Names)

인터넷 서핑을 할 때 브라우저에 입력하는 도메인 주소 체계이다. 도메인의 앞 자리에 사용자명 또는 단말기명을 붙여서 사용한다.

sip:bob.cisco.com

• SMTP와 같은 Domain Names(RFC 2368)

메일주소와 같은 방식을 사용한다.

sip:bob@cicsco.com

• E.164와 같은 주소

사용자 이름 부분에 전화번호를 넣어서 사용한다.

sip:123456789@gateway.com; user=phone

• 혼합된 주소 체계

IP 주소를 함께 사용할 수 있다.

sip:123456789@192.168.0.10; user=phone

sip:123456789@192.168.0.10

주요 SIP Header 분석

일반적으로 SIP 헤더에 포함되는 정보는 다음과 같다.

 INVITE sip:bob@biloxi.com SIP/2.0
 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:alice@pc33.atlanta.com>
 Content-Type: application/sdp
 Content-Length: 142

SIP 헤더의 내용을 대충 이해할 수만 있어도 위의 메시지가 엘리스가 밥에게 보내는 SIP INVITE 메시지로 통화 요청을 위해 생성되었음을 알 수 있다. 각각의 헤더 정보를 살펴보자.

INVITE sip:bob@biloxi.com SIP/2.0

메시지 첫 줄에는 Method와 메시지를 수신하는 최종 단말의 주소와 버전이 명기되므로 메시지가 생성된 목적을 확인할 수 있다.

INVITE : 요청한 메소드
sip:bob@biloxi.com : Request URI
SIP/2.0 : 버전

Request-URI는 일반적으로 To 필드의 URI 값을 이용하여 표시한다. 이 라인은 Biloxi.com 도메인에 속해 있는 밥에게 전화를 걸고 싶다는 의미이다.

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

Via 헤더는 요청에 대한 응답을 위한 경로를 나타낸다. Branch는 시공간에서 유일한 값을 가지며, 트랜잭션 식별자이다. 트랜잭션은 호 설정 또는 호 종료와 같은 단위 작업을 의미하며, User Agent 간에 생성된다.

이 라인의 의미는 SIP INVITE 요청에 대한 응답인 200 OK 를 앨리스에게 바로 전송하지 말고 pc33.atlanta.com 을 경유할 것을 요청한다는 의미이다.

Max-Forwards: 70

시그널링 경로 상에 SIP 서버의 최대 홉 수를 나타낸다. IP 네트워크의 TTL(Time to Live)과 같다.

To: Bob <sip:bob@biloxi.com>

SIP 메시지의 목적지를 나타낸다. 실제 메시지의 라우팅에는 사용되지 않으며 Display Name 의 의미를 가진다.

From: Alice <sip:alice@atlanta.com>;tag=1928301774

SIP 메시지의 출발지를 나타낸다. 실제 메시지의 라우팅에는 사용되지 않으며 Display Name 의 의미를 가진다.

From과 To 헤더는 현재 세션의 진행방향을 의미하는 것으로 현재 메시지의 발신자와 수신자를 의미하는 것이 아니다. 따라서 SIP INVITE 메세지의 응답인 200 OK 에서 From 과 To 헤더의 내용이 바뀌지 않는다. From과 To의 값이 엉뚱하게 적혀있어도 SIP 프로토콜이 진행되는 데는 문제가 없지만, 요즘에는 SIP 보안이 강화가 되면서 From과 To헤더가 잘못 명기되면 호가 진행되지 않기도 한다.

Call-ID: a84b4c76e66710@pc33.atlanta.com

세션에 대한 Global Unified Identifier로 사용하며, 호스트 네임 또는 IP address와 시간을 조합하여 생성된다. To/Fro/Call-ID 의 결합으로 엘리스와 밥사이의 Peer-to-Peer SIP 관계를 정의한다.

Call-ID가 같으면 하나의 다이얼로그로 인식하므로 세션의 설립과 종료 사이의 모든 SIP 메시지는 동일한 Call-ID를 가진다. SIP 호 분석 시에 다수의 호가 혼재되어 있어도 Call-ID를 기준으로 개별 호에 대한 분석이 가능하다. 다이얼로그는 다수의 트랜잭션으로 이루어질 수 있으므로 트랜잭션의 식별은 Via 헤더의 branch 값으로 추적하고, 다이얼로그의 식별은 Call-ID와 From 및 To 의 Tag로 추적한다.

CSeq: 314159 INVITE

Command Sequence 또는 Sequence Number 는 정수와 메소드 이름으로 나타낸다. 새로운 요청을 생성할 때마다 1씩 증가시킨다. 이 요청에 대한 응답인 200 OK에서도 같은 값을 확인할 수 있다.

하나의 요청과 응답은 같은 CSeq 값을 가진다.

Contact: <sip:alice@pc33.atlanta.com>

SIP URI 포멧으로 되어 있으며, 요청을 보낸 사용에 대한 직접적인 경로를 나타낸다.

일반적으로 FQDN(Fully Qualified Domain Name)나 IP주소를 선호한다. Via 헤더 필드가 요청에 대한 응답 경로를 나타내고, Contact 헤더 필드는 미래의 요청을 보낼 경로를 말한다. 요청에 대한 응답은 Via 헤더 필드를 참조하며, 신규 요청을 생성할 경우는 Contact 헤더 필드는 참조하는 것이다.

Content-Type: application/sdp

메시지 바디가 있을 경우, 메시지 바디에 대한 설명이다. application/sdp는 메시지 바디가 SDP 메시지로 구성되었다는 의미이다.

Content-Length: 142

메시지 바디의 크기를 옥텟(바이트)로 표시한다. 메시지 바디가 142 바이트로 구성되었다는 의미이다.

SIP 헤더 분석하기 - SIP Proxy가 없는 경우

실제 구현되는 일반적인 사례는 아니지만, SIP 메시지를 이해하기 쉽도록 SIP 전화기 두 대 사이에 SIP Proxy가 존재하지 않고, 앨리스의 전화기는 Bob의 전화기 IP 주소를 알고 있다고 가정해보자.

INVITE

앨리스가 수화기를 들고 밥의 전화번호를 누르는 순간 아래와 같이 INVITE 메시지가 전송된다.

 INVITE sip:bob@192.168.10.20 SIP/2.0
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:alice@pc33.atlanta.com>
 Content-Type: application/sdp
 Content-Length: 142

From과 To 헤더를 보니 앨리스가 밥에게 보내는 INVITE 요청이다. INVITE의 요청에 대한 응답은 Via 헤더에 표시한 pc33.atlanta.com 을 경유하라고 표시되어 있으며, CSeq를 보니 314519 번의 INVITE 메시지이다. Content-Type 헤더에 메시지를 보니 SIP 메시지에 SDP가 포함되어 있음을 알 수 있다.

200 OK

밥의 전화기는 INVITE를 수신 후에 벨 소리를 재생한다. 밥이 수화기를 드는 순간 200 OK 메시지가 앨리스에게 전달된다.

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:bob@192.168.10.20>
 Content-Type: application/sdp
 Content-Length: 131

From 과 To 헤더는 현재 메시지의 출발지와 목적지가 아닌 호의 진행방향을 나타내는 것이므로 INVITE 메시지의 From 과 To 헤더와 동일하다.

CSeq 헤더는 314159 INVITE 요청에 대한 응답임을 나타낸다. 패킷 분석 시 여러 호가 동시에 진행될 때 어떤 호에 대한 응답인지를 판단할 때 CSeq를 통해 확인한다.

ACK

앨리스의 전화기가 200 OK를 수신하였음을 확인하는 ACK를 전송한다.

 ACK sip:bob@192.168.10.20 SIP/2.0
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 ACK
 Content-Length: 0

CSeq가 314159 이므로 앞의 200 OK에 대한 ACK 임을 확인할 수 있다.

BYE

BYE 세션은 발신자와 수신자 누구나 생성할 수 있다. 수화기를 먼저 내리는 쪽에서 BYE가 전송된다.

 BYE sip:alice@10.1.3.33 SIP/2.0
 Via: SIP/2.0/TCP 192.168.10.20;branch=z9hG4bKnashds8
 Max-Forwards: 70
 To: Alice <sip:alice@atlanta.com>;tag=1928301774
 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 231 BYE
 Content-Length: 0

From 과 To 헤더를 보니 세션의 진행방향은 밥이 앨리스에게 요청하는 다이얼로그이므로 밥이 먼저 수화기를 내려놓았음을 알 수 있다.

200 OK

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP 192.168.10.20
 To: Alice <sip:alice@atlanta.com>;tag=1928301774
 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 231 BYE
 Content-Length: 0

CSeq를 확인해보면, 앞서 전송한 BYE에 대한 200 OK 임을 알 수 있다.

SIP 헤더 분석하기 - SIP Proxy가 있는 경우

실제 SIP 망을 구성할 때는 SIP Proxy 서버나 IP PBX가 항상 존재한다. IP PBX는 제품에 따라 SIP Proxy로 구현하거나 B2BUA로 구현된다. 앨리스의 전화기는 밥의 전화기 주소를 알지 못하므로 INVITE 메시지를 SIP Proxy로 전송하는 과정부터 살펴보자.

앞에서 설명한 부분과 다른 SIP 헤더를 위주로 살펴보자.

INVITE (앨리스가 SIP Proxy 서버로 보내는 것)

앨리스는 밥에게 전송할 INVITE 메시지를 SIP Proxy 서버로 전송한다.

 INVITE sip:bob@biloxi.com/TCP SIP/2.0
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:alice@pc33.atlanta.com>
 Content-Type: application/sdp
 Content-Length: 142

INVITE (SIP Proxy 서버가 밥에게 보내는 것)

SIP Proxy 서버를 경유한 INVITE 메시지는 다음과 같이 Via 헤더와 Max-Forwards 헤더에 변화가 생겼다.

INVITE sip:bob@192.168.10.20/TCP SIP/2.0
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

첫 번째 Via 헤더는 SIP Proxy 서버가 삽입한 것으로 INVITE 요청에 관한 응답이 SIP Proxy 를 경유하도록 요청한다. 그리고 Max-Forwards 헤더가 70에서 69로 줄었다. 한 개의 SIP 서버를 지날 때마다 1씩 줄어든다.

CSeq와 Call-ID가 SIP Proxy를 지나가지만 변경되지 않았다. SIP Proxy 서버는 제한적으로 메시지를 추가/삭제할 수 있지만, 새로운 세션을 생성하지 않는다는 것을 의미한다.

200 OK (밥이 SIP Proxy 서버로 보내는 것)

밥은 INVITE의 Via 헤더를 그대로 복사하여 200 OK에 포함하였으므로 200 OK가 SIP Proxy 서버를 경유한다.

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.168.10.1
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:bob@192.168.10.20>
 Content-Type: application/sdp
 Content-Length: 131

200 OK (SIP Proxy 서버가 앨리스로 보내는 것)

Via 헤더가 하나 줄었다. SIP Proxy 서버가 임의로 삽입한 Via 헤더는 앨리스의 전화기에는 필요가 없으므로 SIP Proxy가 삭제한다.

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Contact: <sip:bob@192.168.10.20>
 Content-Type: application/sdp
 Content-Length: 131

ACK

앨리스의 전화기는 밥의 200 OK 를 정확히 수신했음을 알리는 ACK를 밥의 전화기로 바로 보낸다. ACK는 새로운 신규 요청이므로 다이얼로그 상의 Contact 헤더를 따라 그대로 전달된다.

모든 SIP 메시지를 SIP Proxy 서버를 경유하게 하기

Via 헤더를 통해 INVITE에 대한 200 OK는 SIP Proxy 서버를 경유하지만, ACK 이하의 모든 신규 요청 메시지는 Contact 헤더를 참조하여 단말끼리 직접 송수신을 한다.

기업의 IP PBX는 호의 상태를 관리 및 과금 데이터 생성을 위해 호 절차의 따른 모든 시그널링 메시지가 IP PBX를 경유하도록 한다. B2BUA가 아닌 SIP Proxy 서버가 자신에게 등록된 모든 단말의 시그널링이 경유되도록 하기 위해서는 기존 SIP 헤더를 변경하거나 새로운 SIP 헤더가 필요하다.

아래의 두 개의 새로운 헤더가 필요하다.

• Record-Route Header

옵션 SIP 헤더로 SIP Message를 확인하려는 모든 SIP Proxy에 의해 삽입된다. SIP Proxy를 통해 경유되는 다이얼로그(같은 Call-ID)에 대한 요청과 응답에 사용된다. 여러 대의 SIP Proxy를 경유해야 하는 경우에는 ","를 이용하여 계속 추가한다.

Record-Route: server10.biloxi.com
Record-Route: server10.biloxi.com, bigbox3.atlanta.com

• Route Header

같은 Call-ID의 응답 메시지의 Record-Route Header 로 부터 생성된다. 같은 다이얼로그 내의 첫번째 Transaction이 완료되면, 이후 트랜잭션은 Record-Route Header의 값을 복사하여 Route 헤더로 사용한다.

Route: server10.biloxi.com

특히, 모든 SIP 메시지가 경유되는 SIP Proxy를 Dialog Stateful SIP Proxy 서버라고 한다. Recrod-Route와 Route Header의 사용 방식에 대해 살펴보자.

앨리스의 전화기가 INVITE 메시지를 송신하면 SIP Proxy는 Record-Route 헤더를 삽입하여 밥에게 전송한다. 이를 통해 밥의 전화기는 동일한 Call-ID를 가진 다이얼로그 내의 신규 요청을 SIP Proxy 로 보내게 된다.

 INVITE sip:bob@biloxi.com/TCP SIP/2.0
 Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=10.1.3.33
 Max-Forwards: 69
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Record-Route: server10.biloxi.com
 Call-ID: a84b4c76e66710@pc33.atlanta.com 
 CSeq: 314159 INVITE
 Contact: <sip:alice@pc33.atlanta.com>
 Content-Type: application/sdp
 Content-Length: 142 

밥의 전화기는 INVITE에 대한 응답인 200 OK 에 기존의 Record-Route 헤더를 복사하여 전송한다. ACK는 세션 설립을 위한 마지막 메시지이므로 SIP Proxy는 Rotue 헤더를 제거한 후에 밥에게 전송한다. 호 종료를 위한 BYE는 기존 다이얼로그의 Record-Route 헤더를 복사하여 전송하고, 200 OK는 Via 헤더를 따라 전송되므로 Route 헤더를 삽입하거나 안하거나 상관없다.

REGISTER 의 개요

서로 통화를 해야 하는 전화기의 숫자가 증가할수록 SIP Proxy 서버나 IP PBX를 이용한 중앙집중식 관리가 효과적이다. 단말의 등록은 SIP 컴포넌트인 REGISTRAR 서버가 담당하지만, 기업에서 사용하는 SIP Proxy와 논리적 기능을 같이 구현한다.

전화기는 SIP Registrar 서버에 REGISTER 메소드를 이용하여 전송하면 SIP Registrar 서버는 200 OK를 응답함으로써 등록이 이루어진다.

• REGISTER

Register 메세지의 Request-URI는 SIP Registrar 서버의 주소가 된다. From과 To 헤더는 세션의 진행방향을 의미하는 것이므로 앨리스가 SIP Proxy 서버로 보내는 것임을 알 수 있다.

 REGISTER sip:server19.atlanta.com SIP/2.0
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bk2l55n1
 To: Alice <sip:alice@atlanta.com>
 From: Alice <sip:alice@atlanta.com>;tag=283074
 Call-ID: a84b4g96te10@pc33.atlanta.com
 CSeq: 31862 REGISTER
 Contact: <sip:alice@10.1.3.33>
 Expires: 21600
 Content-Length: 0

REGISTER 메시지의 Expires 헤더는 SIP Proxy 서버에게 21600초 동안 등록을 유지해 줄것을 요청하는 것이다.

• 200 OK

SIP Proxy는 200 OK를 전송하면서 등록을 승인한다.

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bk2l55n1; received=10.1.3.33
 To: Alice <sip:alice@atlanta.com>; tag=a6c85e3
 From: Alice <sip:alice@atlanta.com>;tag=283074
 Call-ID: a84b4g96te10@pc33.atlanta.com
 CSeq: 31862 REGISTER
 Contact: <sip:alice@pc33.atlanta.com>
 Contact: <sip:alice@cm9013.atlanta.com>
 Service-Route: <sip:bigbox3.atlanta.com;lr>
 Expires: 3600
 Contact-Length: 0

SIP Proxy는 Expires 헤더의 값을 21600 초에서 3600초로 변경하였다. SIP Proxy 서버는 전화기에게 한시간마다 재등록할 것을 요청하는 것이다. REGISTER 의 재등록 매커니즘은 일정한 간격으로 이루어지므로 SIP Registrar 서버와 단말간의 Keepalive 매커니즘의 기능을 수행한다.

REGISTER : 사용자가 다수의 전화기를 사용하는 문제

단말의 등록 과정은 단순하지만 200 OK 메시지에 포함된 두 개의 Contact 헤더를 이해하기 위해 한가지 더 고려해보자. 만일 앨리스의 전화기가 한 대가 아닌 여러 대일 경우이다. 요즘 직원들은 PC용 소프트 폰, 데스크탑 IP Phone, 그리고 스마트폰의 전화앱을 사용한다. 여러 대의 전화기가 같은 SIP Proxy 서버에 등록되어 있다고 가정하면, 발신자는 수신자의 단말을 구분해서 전화를 해야 한다. 발신자가 수신자가 받을 수 있는 단말을 예측해서 전화를 걸면 되지만 현실적인 방법은 아니다.

그러므로 발신자가 앨리스의 주소로 전화를 걸면 SIP Proxy는 자신에게 등록된 여러 대의 단말을 동시에 울려주고 앨리스는 받기 편한 전화기를 선택해서 받으면 된다. SIP Proxy 서버가 앨리스가 여러대의 단말을 가지고 있다는 것을 인식하기만 하면 된다. Registrar 서버를 위한 새로운 형식의 주소 체계가 필요하다.

사용자가 여러 대의 단말을 사용해도 문제가 없도록 address-of-record(AOR) URI와 Contact address 라는 개념을 이용한다.

• AOR(Address of Record) 사용자 주소

bob@biloxi.com

• Contact Address 등록된 단말의 주소

bob@phone66.biloxi.com

새로운 주소 체계를 기반으로 생각해보면 전화기의 등록과정은 전화기의 IP 주소와 사용자의 SIP 주소를 연결하는 것이다. 기술적으로는 address-of-record(AOR) URI와 Contact address를 바인딩하는 것이다. SIP 네트워크가 단순히 E.164 전화번호와 IP 주소를 바인딩하여 사용한다면, AoR은 전화번호가 되고 Contact address는 IP 주소가 된다.

앨리스가 밥과 통화 시도 시, 앨리스의 INVITE는 Bob@biloxi.com 주소로 보낸다. 밥이 몇 개의 단말을 사용중이며 현재 통화 가능한 단말이 무엇인지는 biloxi.com의 SIP Proxy 서버만이 알고 있다. 따라서 biloxi.com 도메인 밖에서는 Bob@biloxi.com이 가장 유효한 주소가 되고, biloxi.com의 SIP Proxy 서버는 등록된 단말을 찾을 수 있는 Contact Address 주소가 유효하다. 이런 AOR과 Contact Address 를 바인딩하는 것이 등록(Registration)이다.

등록과정에서 REGISTER 메시지에 대한 200 OK 응답에 2개의 Contact 필드가 있었던 것은 SIP Proxy 서버에 바인딩된 모든 Contact address 정보를 표시하기 때문이다.

REGISTER : SIP Proxy 서버 주소 획득의 문제

UA가 SIP Registrar 서버에 등록하는 과정의 전제는 단말이 SIP Registrar 서버의 주소를 알고 있다는 가정이 필요하다. 또한, 전화기가 등록을 완료한 후에 통화를 위해 INVITE 메시지를 전송할 SIP Proxy 서버의 주소를 획득한다는 가정도 필요하다. 일반적으로 SIP Registrar 서버와 SIP Proxy 서버는 동일한 시스템에서 구현하므로 같은 문제이다. 주소를 획득하는 방법은 여러가지가 있다.

• 전화기(UA)에 직접 입력

가장 많이 사용했던 방법이다. 하지만 UA 설정 정보 관리와 업데이트에 문제가 있다.

• HTTP 또는 TFTP와 같은 프로토콜 활용

TFTP를 이용한 방법은 가장 널리 사용되는 방법이지만, 방화벽 등으로 인해 관리가 복잡하다는 단점이 있다. UA가 SIP외에 다른 프로토콜 엔진을 구동해야 한다.

Registrar 서버의 주소를 획득하는 방법은 표준화가 되어 있지 않으므로 각 제조사별로 다양한 방법을 구사한다. 전화기나 단말에 IP 주소를 할당하는 DHCP 프로토콜은 IP 주소외에 DNS나 TFTP 서버의 주소를 함께 할당할 수 있다. 전화기는 TFTP 서버의 주소를 받은 후 전화기 구성 정보 파일을 다운로드 받으면서 필요한 SIP Proxy 서버나 SIP Registrar 서버의 주소를 획득할 수 있다.

Registrar 서버의 주소는 다양한 경로를 통해 획득하였다고 가정할 경우 SIP Proxy 서버의 주소를 획득하는 방법을 기술한 문서는 IETF RFC 3608 Service Route Extension Header 이다. REGISTER 메시지를 받은 SIP Registrar 서버가 등록을 승인한 후 200 OK 응답 전송 시 Service-Route 헤더에 명시적으로 사용할 SIP Proxy 서버를 통지한다.

CANCEL 의 개요

지금까지 발신자가 전화를 걸면 반드시 통화가 되는 과정을 설명하였지만, 현실에서는 전화를 걸다가 갑자기 수화기를 내려놓은 경우가 종종 있다. 전화번호를 잘못 눌렀다던지 상사분이 갑자기 부른다던지 상대방이 전화를 받지 않는다던지 하는 경우이다.

기존의 요청을 취소하기 위해 SIP CANCEL 메소드를 이용한다. CANCEL은 취소 요청이므로 응답이 발행되기 전에 사용해야 한다. 만일 INVITE 요청에 대해 200 OK 응답을 수신하면 통화중인 상태이므로 CANCEL이 아닌 BYE를 이용해야 한다.

• CANCEL

INVITE 요청에 대한 200 OK 응답 전에 CANCEL을 송신한다.

 CANCEL sip:bob@192.168.10.20 SIP/2.0
 Via: SIP/2.0/TCP 10.1.3.33;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 10197 CANCEL
 Contact: <sip:alice@atlanta.com>
 Reason: SIP ;cause=486 ;text=“Busy Here”
 Content-Length: 0

CANCEL은 취소 사유를 명기하기 위해 Reason 헤더를 이용한다. 위의 메시지에서 Reason 헤더에 표시된 취소 사유는 486 Busy Here 이다.

• 200 OK

앨리스의 CANCEL 요청에 해ㅐ 정상처리하였음을 통지하는 200 OK 이다.

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP 10.1.3.33
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 10197 CANCEL
 Content-Length: 0

200 OK가 INVITE에 대한 것인지 CANCEL에 대한 것인지를 확인하기 위해서는 CSeq 헤더를 참조한다.

위의 그림에서 CANCEL 의 트랜잭션은 요청과 응답으로 정상 처리가 되었지만, INVITE 요청은 아직 아무런 응답을 받지 못했다. 밥의 전화기는 INVITE 에 대한 응답으로 487 Request Terminated 를 발행하고 앨리스는 ACK를 전송하면서 마무리한다.

4XX 응답에 대한 수신 확인을 위해 항상 ACK가 발행된다.

• 487 Request Terminated

밥의 전화기는 CANCEL 요청을 수신한 후에 200 OK를 송신한 후 기존의 INVITE 세션 요청에 대한 처리를 중지하고 487 응답을 발행한다.

 SIP/2.0 487 Request Terminated
 Via: SIP/2.0/TCP 10.1.3.33
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 INVITE
 Content-Length: 0

CSeq 헤더를 통해 INVITE 에 대한 응답임을 알 수 있다.

• ACK

앨리스는 ACK를 전송하여 487 응답을 정상 수신하였음을 통지한다.

 ACK sip:bob@192.168.10.20 SIP/2.0
 Via: SIP/2.0/TCP 10.1.3.33;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 314159 ACK
 Content-Length: 0

== CANCEL - 200 OK 발행과 동시에 CANCEL을 수신했을 경우 발생 확률은 매우 적지만 INVITE에 대한 200 OK를 발행하자마자 CANCEL이 수신되었을 때를 생각해보자. 원격지 단말간에 네트워크로 전송되는 트래픽이므로 충분히 발생할 가능성이 있다.

문제점은 CANCEL은 200 OK 응답 전에 사용한다는 전제를 위해한다는 것이다. 이를 해결하기 위한 방법은 위의 그림과 같이 새로운 메소드를 만들거나 프로세스를 강제를 종료시키는 것이 아닌 기존 트랜잭션을 그대로 활용하는 방법을 사용한다.

앨리스의 전화기는 CANCEL을 발행하자마자 INVITE에 대한 200 OK를 수신하지만 당황하지 않고 200 OK를 정상 수신했음을 통지하기 위해 ACK를 발행한다. 앨리스의 전화기와 밥의 전화기는 기존의 CANCEL 과 INVITE에 대한 트랜잭션을 완료한 후 이미 설립된 세션을 종료하기 위해 BYE를 전송한다.

오류가 발생하지만 모든 트랜잭션을 정상 처리하면서 마무리 짓는다.

CANCEL의 적용 사례 - Call Forking

사용자는 한 개의 전화번호나 URI와 같은 AoR 사용하면서 다수의 단말을 보유한다. 호가 인입되면 SIP Proxy는 AoR과 바인딩 된 모든 단말에 INVITE를 송신하게 되고 200 OK를 보내는 단말을 제외한 나머지 전화기들은 벨이 울리는 것을 멈추도록 기존의 INVITE를 취소해야 한다.

Biloxi.com Porxy 서버는 밥에게 온 INVITE 메시지를 등록된 3개의 단말로 전송한다. 3 개의 INVITE는 Via 헤더의 서로 다른 Branch 값을 가진다. Call Forking 은 시간 간격을 두고 벨을 울리게 하는 순차적인 방법과 동시에 벨을 울리게 하는 방법이 있다. Call Forking 시 Proxy 서버는 200 OK를 송신하지 않은 다른 단말의 호 진행을 중단하기 위해 CANCEL을 발행한다.

• CANCEL

CANCEL 메시지는 기존에 살펴본 것과 동일하며 Reason 헤더의 값만 200 "Call completed elsewhere"로 다르다.

 CANCEL sip:bob@192.168.10.20/TCP SIP/2.0
 Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Server10 <sip:server10.biloxi.com>;tag=1928301774
 Call-ID: a84b4c76e66710@pc33.atlanta.com
 CSeq: 6187 CANCEL
 Contact: <sip:server10.biloxi.com>
 Reason: SIP ;cause=200 ;text=”call completed elsewhere”
 Content-Length: 0

OPTIONS 개요

OPTIONS 메소드는 UA가 다른 UA나 SIP Proxy의 Capability 확인을 목적으로 사용한다. INVITE 요청을 통한 세션 설립과정에서 확인할 수 있는 내용이지만 세션 설립전에 확인할 수 있다는 것이 장점이다. OPTIONS를 이용하여 확인할 수 있는 내용은 다음과 같다.

지원 가능한 메소드
지원 가능한 컨텐츠 타입
확장 헤더
코덱 등

• OPTIONS

 OPTIONS sip:bob@192.168.10.20 SIP/2.0
 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK77i832k9
 Max-Forwards: 70
 To: Bob <sip:bob@biloxi.com>
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com
 CSeq: 22756 OPTIONS
 Contact: <sip:alice@pc33.atlanta.com>
 Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER,
 SUBSCRIBE, NOTIFY, MESSAGE, UPDATE
 Accept: application/sdp, application/pidf-xml
 Content-Length: 0

• 200 OK

 SIP/2.0 200 OK
 Via: SIP/2.0/TCP sip:alice@atlanta.com;branch=z9hG4bK77i832k9
 To: Bob <sip:bob@biloxi.com>; tag=a6c85e3
 From: Alice <sip:alice@atlanta.com>;tag=1928301774
 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com
 CSeq: 22756 OPTIONS
 Contact: <sip:bob@biloxi.com>
 Contact: <sip:bob_home@biloxi.com>
 Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER,
 NOTIFY, MESSAGE
 Accept: application/sdp, text/plain, image/jpeg
 Accept-language: en, fr
 Content-Type: application/sdp
 Content-Length: 274

OPTIONS 및 200 OK 에 나타난 헤더들의 내용은 다음과 같다.

Contact : 자신에게 연결 가능한 Contact address

Allow : 지원 가능한 메소드 리스트

Accept-language : 지원 언어

Accept : Message Body type (Accept 헤더가 없을 경우 "application/sdp"로 가정)

OPTIONS 요청은 긴급을 요하는 메시지가 아니므로 UA가 응답할 수 없는 상황에서는 "486 Busy Here"와 같은 응답으로 대신할 수 있다.

OPTIONS 적용 사례 - OPTIONS PING

UA와 SIP Proxy 서버간의 Keepalibe 매커니즘은 REGISTER 메소드를 이용한다. UA는 등록이 해제(Expires)되기 전에 일정 간격으로 재등록을 시도한다. 일반적으로 SIP Trunk 구간에서 상호간에 등록을 하지 않으므로 REGISTER 메소드를 이용한 Keepalive 매커니즘을 사용할 수 없으므로, INVITE 가 발행되기 전까지는 대상 장비의 Keepalive 상태를 확인할 수 없다. 때문에 SIP 트렁크로 연결된 장비간에 Keepalive 매커니즘을 제공하기 위해서 OPTIONS 메소드를 이용한다.

OPTIONS 메시지를 이용한 Keepalive를 주기적으로 주고 받다가 문제가 있는 장비로 INVITE 메시지를 전송하지 않도록 한다. 만일 OPTIONS PING을 사용하지 않으면 SIP Trunk 구간에서 INVITE에 대한 응답이 수신될 때까지 장비는 기다리거나 Timeout이 완료되어서야 우회루트로 재송신한다. OPTIONS PING은 INVITE에 처리를 빠르게 하기 위한 방법이다.

OPTIONS PING은 장비와 장비간의 직접적인 Keepalive 체크이므로 DNS가 아닌 IP 주소를 사용한다. 만일 FQDN을 이용할 경우 다른 백업 서버로 자동으로 넘어가므로 상대방과의 keepalive 매커니즘에 문제가 발생할 수 있다.

References

<references />