1. SIP의 개요 (RFC 3261)
2. SDP의 개요 (RFC 4566 & RFC 3264)
3. Early Media in SDP (RFC 3959, RFC 3960)
4. RFC 3261의 주요 매쏘드 (I)
5. RFC 3261의 주요 매쏘드 (II)
6. RFC 3261의 Response의 이해
7. PRACK (RFC 3262)
8. SUBSCRIBE & NOTIFY (RFC 3265, RFC 3680)
9. INFO (RFC 2976)
10. UPDATE (RFC 3311)
11. REFER (RFC 3515)
12. PUBLSIH (RFC 3903)
4장에서 설명되지 않은 나머지 매쏘드에 대해 살펴보겠습니다.
CANCEL의 개요 Request를 취소하고자할 경우에 사용합니다. 다음과 같은 경우에 CANCEL 메쏘드가 필요할 것입니다.
발신자가 전화번호를 누른 후에 링백을 듣다가 바로 수화기를 내려놓는 경우
Call Forking과 같은 기능 사용 시 받지 않는 나머지 전화에 대한 INVITE 요청을 취소할 경우
상대방이 일정시간 동안 전화를 받지 않는 경우
CANCEL은 Request에 대한 취소 요청이므로, Request에 대한 Response가 발행되었다면, 취소할 수 없습니다. 예를 들면, INVITE에 대해 200 OK를 수신했다면 이미 통화중인 상태가 되는 것입니다. 이때는 BYE 매쏘드를 이용하여 종료해야 할 것입니다.
다음 그림은 CANCEL의 절차를 나타낸 것입니다. INVITE에 대한 요청이 수락되기전에 CANCEL을 통해 Request를 취소합니다.
그럼 CANCEL의 SIP 헤더 내용을 살펴보도록 하겠습니다. 새롭게 추가된 부분만을 살펴보겠습니다.
Reason 헤더가 새롭게 추가되었으며, CANCEL의 발행 이유에 대해 명기합니다. 원인은 486 Busy Here입니다. 즉, INVITE에 대한 200 OK를 기다리는 사이에 새로운 호가 인입되어 부득이 기존 호를 종료하게 된 것으로 추정할 수 있습니다.
CANCEL에 대해 밥은 200 OK로 수락을 하였습니다. 그러나, 최초 Alice가 전송한 INVITE에 대한 응답을 밥은 아직 하지 못했습니다. 적당한 Response는 487 Request Terminated 일 것입니다. 아래 그림은 일련의 호 절차를 확인할 수 있습니다.
처음으로 INVITE에 대한 Response가 200 OK가 아닌 경우입니다. ^^ 참 4xx Response에 대한 응답은 항상 ACK 입니다. 4xx 는 4장에서도 보았듯이 Request에 대한 실패 (Fail)에 대한 Error 내용입니다.
Call Forking에서의 CANCEL
Call Forking은 아래그림처럼 한 번에 다수의 UA (User Agent)에 INVITE를 동시 또는 순차적으로 전달하는 것을 의미합니다. 이중에 하나의 UA가 200 OK를 전송하면, 나머지 UA는 CANCEL을 전송하여 요청을 취소하게 되는 서비스입니다. 아래 그림에서 보면, 밥은 Biloxi.com Proxy 에 3대의 전화기를 등록해 놓았으며, Call Forking 서비스를 지원받고 있습니다.
위의 그림은 순차적으로 Call Forking이 진행되는 것이며, 아래는 동시에 Call Forking이 되는 그림입니다.
이 때 CANCEL 헤더 메세지를 살펴보도록 하겠습니다. 아래그림에서 Reason 헤더의 값은 200 "Call completed elsewhere" 입니다.
OPTION의 개요 UA는 OPTION 메쏘드를 통해 UA 또는 SIP Proxy의 Capability를 링을 울리지 않고도 조용히 확인할 수 있습니다. 확인할 수 있는 정보는 다음과 같습니다.
Method
Content types
extensions
codecs
아래 그림은 간단한 OPTION 요청과 응답을 나타낸 것입니다.
OPTION의 내용을 살펴보겠습니다. Allow 와 Accept 헤더를 통해 엘리스는 밥에게 정보를 제공합니다.
아래 그림에서 보듯이 밥은 200 OK를 통해 다음과 같은 정보를 제공합니다.
잘 알려진 Contact (Contact 헤더)
지원 메쏘드 (Allow 헤더)
언어 (Accept-language 헤더)
Message Body type (Accept 헤더)
지원 코덱 (SDP) : 포토번호가 0으로 설정됨
REGISTER 의 개요 SIP에 있어서 등록과정은 필수적인 요소입니다. SIP Proxy Server는 옵션이지만, 단말의 숫자가 증가할 경우 모든 경로에 대한 정보를 단말이 보유하는 것은 불가능하므로 일반적으로 SIP Proxy Server (일반적으로, Registra Server와 함께 구현됨)를 사용하며, 단말들은 등록과정을 진행합니다. 등록과정을 통해 SIP Proxy Server는 단말의 현재 위치를 확인할 수 있습니다. 즉, address-of-record (AOR) URI와 Contact address를 바인딩하는 것입니다. 여기서 AOR과 Contact address에 대해 짚어보도록 하겠습니다.
AOR (Address of Record)
외부 도메인에서 현재 통신하려는 사용자 Bob@biloxi.com
엘리스가 밥과 통화를 할려고 합니다.그러면 엘리스는 밥에게 접근하기 위해 INVITE를 보낼 것입니다. 밥은 3개의 단말을 가지고 있으며, 어느것이 현재 등록되어 있는 지는 biloxi.com의 SIP Proxy Server 만이 알고 있습니다. 따라서, biloxi.com 도메인 밖에서는 Bob@biloxi.com이 가장 유효한 주소이며, biloxi.com의 SIP Proxy Server 에서는 등록된 단말을 찾을 수 있는 주소가 유효해 지는 것입니다. 이런 AOR과 Contact Address를 바인딩하는 것이 등록 (Registration)입니다.
아래 그림은 일반적인 등록 과정입니다. 단순히 REGISTER 요청에 200 OK로 응답하면, 등록이 되지만, 자세한 메세지에 대해서도 짚고 넘어가도록 하겠습니다.
엘리스는 자신의 정보를 SIP Proxy Server에 등록을 시도합니다. 이때, Proxy Server의 주소를 아는 것은 다양한 방법이 있겠지만,일반적으로 사전 설정을 통해 UA가 등록을 시도할 수 있도록 합니다. 이때 메세지는 아래와 같습니다. 엘리스는 21600초 동안 등록을 유지해 줄 것을 Expires 헤더를 통해 알립니다. 200 OK 응답의 경우 3600초 동안 등록 정보를 유지하겠다고 합니다.
200 OK의 Contact 에는 항상 현재 바인딩되어 있는 주소 정보를 표시합니다.
또한, 200 OK에는 Service-Route 헤더가 있습니다. 이 헤더는 RFC 3608 SIP Extension Header Field for Service Route Discovery During Registration 에 정의되었습니다. 이 헤더는 등록과정에서 UA가 SIP Home Proxy Server 정보를 획득할 수 있도록 해 주는 것입니다.
RFC 3608 상의 Service Route Header의 이해 등록 과정에서 UA의 AOR과 Contact address가 바인딩 되어 있으므로, SIP Proxy로 온 INVITE 요청은 Contact address로 정확히 전달될 것입니다. 반대로, UA에서 Outbound를 위해 INVITE를 생성하여 전송하려고 할 때 사용할 수 있는 Proxy에 대한 정보를 획득하는 방법이 필요합니다. 다음과 같이 여러가지 방법이 있습니다.
UA에 수동 설정
UA 설정 정보 관리와 업데이트에 대한 이슈가 발생하지만, 가장 많이 사용합니다. Proxy가 자주 바뀐다고 한다면, 정말 골치가 아픈 일이 발생하게 될 것입니다.
HTTP또는 TFTP와 같은 프로토콜을 이용하여 UA의 설정 정보 전달
이것 또한 많이 사용하는 방법입니다. 방화벽이 많으면 관리가 복잡해지는 문제가 있고, UA는 SIP외에 다른 프로토콜 엔진을 구동해야 할 것입니다.
Lookup table 활용
데이타베이스에 대한 오버헤드 발생
위의 언급된 것 말고도 RFC 3608에는 302 Temprary Moved Response를 활용하는 방법이나 Record-Route 헤더를 REGISTER 매쏘드에서도 활용하는 방법등이 열거되어 있습니다만 결국 RFC 3608의 Service Route Extension Header를 사용할 것을 권고합니다. 실제 Enterprise 급 장비는 이런 필드가 필요없을 수도 있습니다만, 거대 3GPP망 같은 경우에는 상당히 다른 경우가 될 것입니다.
다음 그림과 같은 망 구조로 된 3GPP망(핸드폰 망) 을 생각해 봅시다.
UA1은 Visited Network에 있으며, UA1은 수동 설정 또는 DHCP에 의해 Proxy 1의 주소를 획득한다고 가정합니다. 여기서 UA1 실제 Outbound Service를 Home Service Proxy의 주소를 획득하는 것이 필요합니다. 이 때 REGISTER request에 대한 200 OK 응답에 Service Route 헤더를 이용하여 알려줍니다. 이과정은 RFC 3608에 자세히 나와 있습니다.
UA1이 다음과 같은 REGISTER 메세지를 전달하면, Proxy 1은 Response를 받기 위해 Via 헤더를 추가하여 Edge Proxy로 전달할 것입니다. Edge Proxy Server도 Via 헤더를 추가하여 Registrar Server에 전달합니다. 즉 REGISTER 요청에 3개 Via 헤더가 추가될 것입니다.
Registrar Server는 SIP URI (AOR) 주소와 Contact 주소를 바인딩합니다. 또한, Registrar Server는 수동 설정 또는 기타 다른 방식을 통해 Home Service Proxy 및 Edge Proxy의 주소를 알고 있으므로, 이를 통해 Service-Route를 생성합니다. 다시 Via 경로를 따라 최종 UA1에 전달된 200 OK에는 다음과 같은 정보를 담게 됩니다.
Service-Route 헤더에는 Edge Proxy와 Home Service Proxy의 정보가 담기게 됩니다. UA 1은 Service Route 정보를 저장하여 향후 발생할 요청에 사용합니다. 이렇게 간단하게 Proxy Server의 정보를 획득할 수 있습니다. 이를 통해 UA2를 찾아가는 INVITE 메세지에는 Route 헤더를 포함하여 전달되게 됩니다.
실제 INVITE 메세지는 Proxy 1 --> Edge Proxy --> Home Service Proxy 를 거쳐 전달됩니다. Home Service Proxy는 UA2의 Contact Address를 획득하여 INVITE 요청을 Edge Proxy로 전달하고, Edge Proxy는 UA2로 직접 전달하게 됩니다. 아래 그림은 Home Service Proxy가 Edge Proxy로 전달한 INVITE메세지 입니다.
마치며
이렇게 RFC 3261를 기준으로 하는 요청 메세지 (메쏘드)를 모두 살펴보았습니다. 다음장에서는 제가 알고 있는 부가 서비스와 이를 위한 Response들에 대해 자세히 살펴보겠습니다.
