1. SIP의 개요 (RFC 3261)
2. SDP의 개요 (RFC 4566 & RFC 3264)
3. Early Media in SDP (RFC 3959 & RFC 3960)
4. RFC 3261의 주요 매쏘드 I (RFC 3261)
5. RFC 3261의 주요 매쏘드 II (RFC 3261)
6. RFC 의 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장째입니다. 다른 연재들 처럼 천천히 연재하다가 과중한 업무로 인해 중단되는 일을 반복하지 않기 위해 SIP 연재를 조금 빠르게 진행하겠습니다. 이 연재로 SIP를 공부하시는 분들에게 도움이 되었으면 합니다. 그럼 시작하겠습니다.
SIP Methods 개요
이제 기본적인 SIP의 호 프로시져와 SDP를 통한 코덱 협상에 대해 충분히 이해하셨을 것입니다. 이제 기본적인 INVITE, 200 OK, ACK에서 벗어나서 다양한 SIP Method에 대해 알아보겠습니다. 물론, 200 OK는 매쏘드가 아니라 Response입니다.
위의 그림에서 처럼 SIP는 Request에 대한 Response로 동작합니다. Request에 대한 응답은 다음과 같은 경우가 있겠습니다.
- Accept
요청을 승인하고, 200 OK를 송신
- Reject
요청을 거절하고, 사유에 따른 response를 송신
- Redirect
요청을 수신할 다른 주소를 송신
Response에 대해서는 6장에서 자세히 다루도록 하겠습니다.
SIP의 주요 매쏘드
RFC 3261에 정의된 6개의 매쏘드는 다음과 같습니다.
- INVITE
멀티미디어 세션에 참가시키기 위한 서비스 또는 사용자를 초대하기위한 매쏘드
- ACK
사용자가 INVITE Request에 최종 응답 (200 OK)를 받았음을 확인하기 위한 매쏘드
- BYE
기존의 세션을 종료하기 위한 매쏘드
멀티미디어 세션의 참가자 누구나 전송 가능
- CANCEL
기존의 Request를 취소하기 위한 매쏘드
만일 기존의 요청에 200 OK를 받았다면 취소할 수 없음
- OPTIONS
서버의 Capability 를 요청하기 위한 매쏘드
- REGISTER
User Agent가 Registrar Server에 등록하기 위한 매쏘드
이것 외에 멀티미디어 세션 관리 및 추가 서비스를 위해 다음과 같은 8개의 매쏘드가 정의되어 있습니다.
- INFO (RFC 2976)
기존의 성립된 세션 또는 다이얼로그 내에서 추가적인 정보를 전송하기 위한 매쏘드
- PRACK (RFC 3262)
UAC (User Agent Client)가 임시적으로 Response를 승인하기위한 매쏘드
- SUBSCRIBE (RFC 3265)
특정 이벤트를 살펴보기 위해 원격노드에 요청하기 위한 매쏘드
- NOTIFY (RFC 3265)
특정 이벤트 발생 시 응답하기 위한 매쏘드
- UPDATE (RFC 3311)
세션 설정 파라미터를 업데이트하기 위한 매쏘드
- MESSAGE (RFC 3428)
SIP IM (Instant Messaging)을 위한 매쏘드
- REFEER (RFC 3515)
UA가 지금 통신 중인 UA 이외의 또 다른 UA와 통신하기 위한 매쏘드
- PUBLISH (RFC 3903)
Presence Server에 UA의 상태정보를 전송하기 위한 매쏘드
이렇게 총 14개의 매쏘드가 있습니다. 매쏘드를 알면, SIP를 통해 어떤 서비스가 가능한 지도 알수 있겠습니다.
일반적인 호 절차 (INVITE, ACK, BYE)
일반적인 SIP 호 절차는 다음과 같습니다. 이 절차에 대한 자세한 설명은 "RFC 3261 분석"에 나와 있으므로 생략하도록 하겠습니다. 아래 그림은 엘리스가 정확하게 Bob의 주소를 정확하게 알고 있을 경우에 가능할 것입니다.
일반적인 호 절차 (INVITE, ACK, BYE with Proxy)
엘리스는 밥의 주소를 알 수 없기 때문에 Proxy서버를 이용하여 밥의 정확한 주소를 확인할 수 있습니다. 이 때 엘리스는 SIP Proxy서버의 주소만을 알고 있으면, 모든 목적지로 INVITE를 전달할 수 있습니다.
SIP Proxy는 엘리스로부터 전송된 INVITE request에 via 헤더를 삽입하여, 200 OK가 자신을 경유하도록 설정하여 위의 그림과 같은 프로시저가 이루어집니다. 자세한 메세지는 역시 "RFC 3261 분석" 글을 참조하시기 바랍니다.
Dialog Stateful (INVITE, ACK, BYE with Proxy)
아래 그림와 같이 Invite 뿐만 아니라 ACK 및 BYE 메세지까지 Proxy Server를 경유하도록 할 필요가 있습니다. 호 다이얼로그 상태를 감시하거나 메세지의 내용을 변경하고자 할 경우, 과금 및 CDR을 생성해야 할 경우 등에 유용합니다. 이 때 사용하는 것이 Route 헤더 및 Record-Route 입니다. INVITE에 대한 응답인 200 OK는 via 필드를 이용하여 메세지로 전송되고, 나머지는 Record-Route 헤더를 이용합니다.
- Record-Route Header
SIP Message를 확인하려는 모든 SIP Proxy에 의해 삽입 가능
SIP Proxy를 통해 경유되는 dialog (같은 Call-ID)에 대한 Request and Response 에 사용
- Route Header
Dialog 상의 Response의 Record-Route Header로 부터 생성
엘리스가 보낸 INVITE 메세지는 SIP Proxy를 경유하면서, 두가지 필드가 추가될 것입니다. 하나는 Via 필드이고, 또 하나는 Record-Route 또는 Route 헤더입니다. 200 OK를 Via 필드를 참조할 것이며, ACK 및 BYE는 Record-Route 헤더를 참조하여 전송 됩니다.
아래 그림은 엘리스가 보낸 INVITE 메세지가 SIP Proxy에 의해 변경된 내용을 붉은 색으로 표시한 부분이 추가된 사항이며, 이를 통해 SIP Proxy가 호 프로시저의 전체에 관여할 수 있게 됩니다.
마치며
이렇게 전체적인 호 구조 및 주요 헤더에 살펴보았습니다. 설명을 하다보니 항상 정상적인 상황에서의 호 절차에 대해서만이 이루어졌습니다. 다양한 요청에 대한 Response 상황에 따른 호 처리 프로시저를 6장 정도에서 다루도록 하겠습니다.
SIP 연재를 읽으시는 분들이 어렵다라는 말씀을 하시는 데 아직 틀렸다는 얘기가 없습니다. ^^ 워낙 급조해서 정리하다보니 잘 못된 부분들이 있을 수 있음을 인지하시고, 틀린부분은 알려주시기 바랍니다.
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에 대해 짚어보도록 하겠습니다.
어렵습니다. 아래 그림을 보면 좀 더 쉽게 이해할 수 있습니다.
엘리스가 밥과 통화를 할려고 합니다.그러면 엘리스는 밥에게 접근하기 위해 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들에 대해 자세히 살펴보겠습니다.
이제 절반 정도 왔습니다. 6장 이후의 차례가 아무래도 대폭 변경될 듯합니다. 생각보다 내용이 점점 많아지기도 하고, 불필요한 부분이 생기기도 합니다. 차례가 바뀌거나 없어져도 놀라지 마시고, 읽어 주시기 바랍니다. SIP에 대한 전체적인 내용이 담기도록 노력하겠습니다.
개요
SIP는 Request and Response 프로토콜이라고 설명드렸습니다. 지금까지는 Request 위주로 살펴보았다면, 이 장에서는 Response에 대해 살펴보겠습니다. 아래 표는 자주 사용되는 Response 입니다.
1XX Informational Responses
Informational Responses는 Request에 대해 Final Response 전에 약 200ms 이상의 시간이 소요되면 서버가 처리중임을 위해 전송됩니다. 이 Response에는 SDP와 같은 Body가 함께 전송될 수 있습니다.
- 100 Trying
Request는 다음 서버로 전송되어 처리 중임을 의미합니다. 만일 데이타베이스에 대한 쿼리가 진행중이라면, 응답이 늦어져 최초 Request가 재송신될 수 도 있습니다. 이를 막기위해 100 Trying을 UAC로 전송합니다.
- 180 Ringing
가장 많이 보는 Response 가운데 하나입니다. UAS가 사용자에게 Alerting 중임을 나타내고 이를 수신한 UAC는 Local Ringback tone을 재생할 것입니다.
- 181 Call Is Being Forwarded
만일 UAS가 Call Forward Busy 또는 Call Forward No answer로 착신전환되어 있을 경우 Proxy는 INVITE를 착신전환 번호로 재송신 중임을 UAC에게 알려주기 위해 사용합니다.
- 182 Queued
착신측 UAS가 일시적으로 통화를 할 수 없는 상태일 때 호를 거절하지 않고 큐에 넣어 놓았다가 UAS가 통화가 가능해지면 호를 재 연결합니다. 이런 경우는 IPCC 와 같은 곳에서 많이 유용할 것입니다. 모든 상담원이 통화중이라면, 큐에 넣어 놓았다가 다시 상담 대기상태로 전환된 상담원에게 연결하는 상황에 사용됩니다.
- 183 Session Progress
위에 열거되지 않은 상황에 대한 호 진행 정보를 전송할 때 사용한다고 보시면 됩니다.
2XX (Successful)
다들 아시는 것일 것입니다. Request가 정상적으로 처리되었음을 의미합니다. 대표적인 것이 200 OK 입니다.
3XX Redirect
사용자의 새로운 UA 에 대한 정보로 응답합니다.
- 300 Multiple Choices
사용자가 여러개의 단말을 소유할 수 있으며, 이에 따라 선호하는 UA로 호를 진행합니다.
- 301 Moved Permanently
사용자가 더이상 Request-URI의 주소로 찾을 수 없음을 의미하며, reponse에 포함된 Contact Header 주소로 re-INVITE를 진행해야 합니다. 또한, Local Directories, 주소록 등에 정보를 업데이트 해야 합니다.
- 302 Moved temporarily
사용자가 다른 곳으로 옮겼으며, reponse에 포함된 Contact Header 주소로 re-INVITE를 진행해야 합니다. 301과 차이라면, 일시적인 이동임으로 Local Directories에 업데이트할 필요가 없습니다.
- 305 Use Proxy
UAS에 도달한 Request가 Proxy를 경유하지 않아 경유하도록 Contact address를 보냅니다.
- 380 Alternative Service
이 Reponse는 한 번도 보지 못한 것입니다. 진행된 호는 실패했지만, 다른 서비스가 가능함을 의미한다고 되어 있는 데 무슨 말인지 모르겠습니다. ^^
4XX Request Failure
호를 진행할 수 없는 사유가 나타납니다. UA는 메세지 변경없이 같은 Request를 반복해서는 않됩니다. 4XX는 매우 많은 Reponse가 정의되어 있습니다. 자세한 사항은 RFC 3261 21장을 보시기 바랍니다. 저도 적다가 포기했습니다. -,-:?
- 400 Bad Request
잘못된 문구나 메세지 포맷을 따르고 있지않아 처리될 수 없슴을 의미합니다. 예를 들면, 필수적인 SIP 헤더가 빠져있다던가 할 수 있을 것입니다.
- 401 Unauthorised & 407 Proxy Authentication Required
Request는 사용자 인증을 요구합니다. Registrar 또는 UAS에 의해 401 Response가 발행되며, Proxy Server에 의해 407 Response가 발생됩니다.
- 403 Forbidden
서버는 Request를 이해했지만, 처리를 거절합니다.
- 404 Not Found
Request-URI에 있는 도메인 주소가 존재하지 않음을 의미합니다.
- 406 Not Acceptable
Accept Header에 열거되지 않은 사항을 요구할 경우 전송됩니다.
- 408 Request Timeout
일정 시간안에 Request에 대한 응답을 할 수 없음을 의미합니다.
5XX Not Implemeted
서버 상에 구현되지 않은 서비스를 요구할 경우에 사용됩니다. 자세한 사항은 생략합니다.
Redirect (302 "Moved Temporarily")
다음 그림은 엘리스가 밥의 데스크탑 전화기로 INVITE 요청을 한 경우입니다. 밥은 Call Forward All (착신 전환) 또는 착신 선호 UA 변경과 같은 설정을 한 상태로 가정할 수 있습니다. 이때 INVITE 요청에 대한 302 "Moved Temporarily" Response가 Redirect Server에 의해 전송됩니다. 이 때 302 Response 내의 Contact 헤더는 re-INVITE를 전송할 주소가 명기되고 re-INVITE 가 밥의 소프트폰으로 전송됩니다.
일반적으로 Redirect Server는 SIP Proxy와 함께 구현이 됩니다. 만일 Call Forward All을 설정하였으나, SIP Proxy내의 Bob의 프로파일에 따로 설정변경이 이루어지지 않고 전화기 상에서만 구현되었다면 아래 그림과 같은 Redirect가 발생할 것입니다.
실제 호 절차는 SIP Proxy에 의해 이루어지나 Bob의 전화기에 의해 발생하나 마찬가지 절차를 수행한다는 것을 알수 있습니다.
착신측이 지원하지 않는 코덱을 사용할 경우 ( 488 "Not Acceptable Here")
엘리스는 G.711로 호를 개통하기 위해 INVITE 요청을 밥에게 보내지만, 밥은 G.729만을 지원합니다. 이 때 488 "Not Acceptable Here"라고 응답을 하며, 이 메세지에 선호되는 코덱이 SDP 메세지에 명기될 것입니다. 따라서, re-INVITE에 G.729로 개통하자는 호가 진행됩니다.
통화중 (Called party Busy, 486 Busy Here)
SIP Proxy가 밥의 상태 정보를 인지하지 못할 경우 INVITE 요청이 밥에게 전달되고, 밥은 다른 사람과 통화중이라면 "486 Busy Here" 에러 메세지를 전달합니다.
여기에서는 통화중일 경우를 가정하여 설명했지만, UAS (착신측 UA)가 호를 진행할 수 없는 모든 상황에 대해 보낼수 있습니다. 또한, 비슷한 Response로는 600 Busy Everywhere 와 488 Not Acceptable Here 도 가능합니다. 600 은 호를 응답할 수 있는 다른 시스템도 없을 경우이며, 호를 거절하기할 경우 488 응답을 전달하며, 정확한 거절사유가 명기되어야 합니다.
착신전환
다양한 경우나 상황에서 착신전환은 이루어질 수 있습니다. Call Forward All, No answer, Busy 이 외에도 Proxy의 설정에 따라 다양한 방식의 착신 전환을 지원합니다. 각각의 상황에 대해 살펴보겠습니다. 아래 그림은 Call Forward Busy 상황입니다.
통화중일 경우의 호 절차는 이미 살펴보았으며, 486 "Busy Here"를 받은 Proxy는 INVITE를 다시 정해진 Call Forward Busy 번호로 요청하면서 동시에 발신자인 엘리스에게 181 "Call is being Forwarded"를 전송합니다. 밥의 관리자로 포워딩 된 호는 Ringing 메세지를 전달받아 엘리스에게 전달하게 되어 나머지 절차가 진행됩니다.
그렇다면 Call Forward No Answer의 경우는 어떻게 될지 아래 그림을 살펴보겠습니다.
180 Ringing 후에도 일정시간동안 200 OK가 Proxy로 전달되지 않으므로 Proxy는 CANCEL을 요청하고, Call Forward No Answer 번호로 호전환이 이루어집니다. 착신측이 음성사서함이므로 별도의 180 Ringing 메세지없이 바로 200 OK가 전달될 것입니다. 또한 바로 음성 프롬프트가 진행될 것입니다.
Gateway Congestion
만일 Proxy 가 보낸 INVITE를 처리할 DSP가 Gateway 내에 없다면, 아래의 그림과 같은 503 "Service Unavailable"로 응답합니다.이에 Proxy는 두번째 게이트웨이로 다시 호를 시도합니다. 이런 프로세스가 진행될 수 있도록 Proxy에 설정되어 있어야 합니다.
마치며
다양한 XXX Response에 대해서는 RFC 3261를 참조하시기 바랍니다. 나중에 이를 이용한 다양한 부가서비스 구현에 대해서는 패킷을 분석해가면서 보도록 하겠습니다. 우선은 표준에 중심을 두고 전개하도록 하겠습니다.
