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)
이제 절반 정도 왔습니다. 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를 참조하시기 바랍니다. 나중에 이를 이용한 다양한 부가서비스 구현에 대해서는 패킷을 분석해가면서 보도록 하겠습니다. 우선은 표준에 중심을 두고 전개하도록 하겠습니다.
