Chapter 4. SIP Response
SIP는 요청과 응답(Request / Response) 프로토콜입니다. RFC 3261에 설명된 주요 요청 메쏘드인 INVITE, ACK, BYE, REGISTER, CANCEL, OPETIONS 를 살펴보면서 200 OK 응답만을 살펴보았습니다. 정상응답외에 발생할 수 있는 다양한 응답들을 살펴보겠습니다. 


1.  SIP Response의 개요 
SIP 요청에 대한 응답이 이루어져야 트랜잭션이 완료됩니다. 요청에 대한 응답이 없을 경우에는 사전 정의된 타이머(Timer)까지 기다린 후에 재송신됩니다. 


SIP 응답은 일렵 번호가 정의되어 있으며, 일련 번호 앞자리만 보아도 일반적인 의미를 해석할 수 있습니다.


  • 1xx Provisional : 정보

  • 2xx Success : 정상
  • 3xx Redirection : 요청을 다른 주소로 재송신
  • 4xx Client Error : 클라이언트 장애
  • 5xx Server Error : 서버 장애
  • 6xx Global Failure : 사용자 연결은 가능하지만 통화불가


2. 1xx Provisional Responses
1xx Informational Responses라고도 하며 요청에 대해 최종응답(Final Response) 전에 요청을 처리하는 시간이 200ms 이상일 때 서버가 처리중임을 통지하기 위해 발행합니다. 1xx 응답에는 SDP와 같은 SIP 메세지 바디가 함께 전송되기도 합니다. 

  • 100 Trying
    수신된 요청을 다음 서버로 전송하거나 처리 중임을 의미합니다. 만일 데이타베이스에 대한 쿼리나 상대방으로 부터의 응답이 늦어 최종응답을 보내지 못할 경우 송신자는 요청에 대한 재송신을 할수도 있으므로 100 Trying을 UAC로 전송합니다.

    일반적으로 INVITE와 같은 요청을 받아서 즉시 처리할 수 없을 경우에 거의 대부분 발행됩니다. 


  • 180 Ringing
    UAS가 사용자에게 Alerting (전화기의 링을 울림) 중이므로 UAC에게 Ringback tone을 재생하거나 준비할 것을 통지하는 것입니다.

    호 절차 상 발신자가 링백톤을 듣는 다면 호가 거의 설립된 것으로 간주되므로 중요한 응답입니다. 

     
  • 181 Call Is Being Forwarded
    UAS가 착신전환되어 있으므로 현재 호가 착신전환 번호로 재시도 중임을 UAC에게 통지하는 것입니다.  


  • 182 Queued
    UAS가 일시적으로 통화를 할 수 없는 상태일 때 호를 대기 큐에 넣은 후 UAS가 통화가 가능해지면 호를 재 연결할 것임을 통지합니다. 

    예를 들면, IPCC 와 같은 고객센터에서 모든 상담원이 통화중일 경우 상담원이 통화가 가능해 질 때까지 호는 큐잉되어 음악이나 큐잉메세지를 듣게 됩니다. 

     
  • 183 Session In Progress
    진행중인 호에 대한 추가적인 정보를 전송하기 위해 사용합니다.

    일반적으로 잘 사용하지 않지만, 간혹 사용됩니다.

  • 199 Early Dialog Terminated
    RFC 6228 SIP Response Code for Indication of Terminated Dialog 에 새롭게 명시된 응답으로 UAS와 SIP Forking Proxy가 최종 응답전에 다이얼로그가 종료되었음을 통지합니다.  


2. 2xx Successful
Request가 정상적으로 처리되었음을 의미합니다. 문서 상에는 202와 204가 표시되어있지만, 실제 200 OK 이외의 응답을 본 적이 없습니다.  

  • 200 OK
    요청을 성공적으로 처리하였음을 통지합니다.

  • 202 Accepted
    요청은 처리를 위한 승인이 되었지만, 아직 처리중임을 통지합니다.

  • 204 No Notification
    RFC 5839 An Extension to SIP Events for Conditional Event Notification에 명시된 응답으로 기존 다이얼로그 내에서 SUBSCRIBE 메세지와 관련된 응답이 보내지지 않았음을 표시합니다.  



3. 3xx Redirect

사용자의 새로운 위치나 UA 정보 또는 호를 위한 변경된 서비스로 응답합니다.

  • 300 Multiple Choices
    사용자가 여러개의 단말을 소유할 수 있음을 의미하므로 선호되는 UA로 호를 진행합니다.
     
  • 301 Moved Permanently
    요청된 Request-URI의 주소로 단말을 찾을 수 없음을 의미합니다. 사용자는 응답에 포함된 Contact 헤더 주소로 re-INVITE를 진행하고, Local Directories, 주소록 등에 정보를 업데이트합니다.
     
  • 302 Moved temporarily
    일시적으로 다른 곳으로 이동했음을 의미합니다. 발신자는 응답에 포함된 Contact Header 주소로 re-INVITE를 진행합니다. 일시적인 이동이므로 Local Directories에 업데이트할 필요가 없습니다. 

  • 305 Use Proxy
    UAS에 도달한 Request가 Proxy를 경유하지 않았음을 의미합니다. UAS는 메세지가 SIP Proxy를 경유하도록 Contact address를  포함합니다.  
     
  • 380 Alternative Service
    진행중인 서비스 요청은 실패하였으나 다른 서비스는 이용 가능하다는 것을 의미합니다. 


 

4. 4xx Request Failure
호의 실패를 의미하므로 실패 이유를 명기하여 응답합니다. UA는 메세지 변경없이 같은 Request를 반복해서는 않됩니다.  

  • 400 Bad Request
    잘못된 문구나 메세지 포맷을 따르고 있지않아 처리될 수 없음을 의미합니다. 필수적인 SIP 헤더가 빠져있을 때 발행됩니다.

  • 401 Unauthorised & 407 Proxy Authentication Required
    요청은 사용자 인증이 필요함을 의미합니다. Registrar 또는 UAS는 401 응답을 발행하고, SIP Proxy 서버는 407 응답을 발행합니다.  

  • 403 Forbidden
    서버는 Request에 대한 처리를 거절함을 의미니다. 

  • 404 Not Found
    Request-URI에 있는 도메인 주소가 존재하지 않음을 의미합니다. 

  • 406 Not Acceptable
    Accept Header에 열거되지 않은 컨텐츠 타입을 요구함을 의미합니다.

  • 408 Request Timeout
    일정 시간안에 Request에 대한 응답을 할 수 없음을 의미합니다. 

  • 410 Gone
    요청한 자원이 서버에서 고정적으로 이용 가능하지 않음을 의미합니다. 

  • 413 Request Entity Too Large
    Request의 내용이 서버가 처리할 수 있는 것보다 너무 큼을 의미합니다. 일시적인 상황일 경우 Retry-After 헤더로 UAC가 재시도할 수 있음을 표시합니다. 

  • 414 Request-URI Too Long
    Request-URI가 서버가 해석할 수 있는 길이보다 길다는 것을 의미합니다.

  • 415 Unsupported Media Type
    서버는 메세지 바디에 서버가 지원되지 않는 포맷으로 요청함을 의미합니다. 서버는 반드시 Accept, Accept-Encoding, 또는 Accept-Language 헤더 등을 이용하여 응답해야 합니다.

  • 416 Unsupported URI Scheme
    Request-URI 스킴을 서버가 해석할 수 없음을 의미합니다. 

  • 420 Bad Extension
    서버는 Proxy-Require 나 Require 헤더에 정의된 Extension (확장)을 이해하지 못함을 의미합니다. 서버는 반드시 Unsupported Header 에 지원하지 않는 Extension을 명기하여 응답합니다.

  • 421 Extension Required
    UAS는 Request를 처리하기 위해 특정 Extension이 필요하지만, Supported Header에 명기되지 않았음을 의미합니다. UAS는 응답시에 Require헤더에 필요한 Extension을 명기해야 합니다.

  • 423 Interval Too Brief
    Request에 의해 자원을 확보하기 위한 시간이 너무 부족함을 의미합니다. 

  • 480 Temporarily Unavailable
    상대방을 성공적으로 연결하였지만, 현재 상대방이 응대가능하지 않음을 의미합니다. 예를 들면, 로그인은 했지만 통화가 않되거나 Do not Disturb 기능을 이용 중일 경우입니다.  

  • 481 Call/Transaction Does not Exist
    UAS가 기존 다이얼로그 나 트랜잭션과 매치되지 않는 요청을 받았음을 의미합니다.

  • 482 Loop Detected
    UAS가 루프 상황을 검출하였음을 의미합니다. Via 헤더에 값을 통해 전 서버에서 보낸 요청이 다시 돌아 왔음을 알수 있습니다. 

  • 483 Too Many Hops
    서버는 Max-Forwads 헤더 값이 0인 Request를 받았음을 의미합니다.

  • 484 Address Incomplete
    서버는 불완전한 Request-URI를 가진 Request를 받았음을 의미합니다. 

  • 485 Ambiguous
    서버는 애매모호한 Request-URI를 가진 Requestf를 받았음을 의미합니다. 서버는 응답 시에 Contact 헤더에 명확한 주소를 리스팅합니다. 

  • 486 Busy Here
    상대방을 성공적으로 연결하였지만, 현재 상대방이 응대가능하지 않음을 의미합니다.

  • 487 Request Terminated
    Request는 BYE나 CANCEL 요청에 의해 종료되었음을 의미합니다. CANCEL 요청에 대한 응답으로 사용되지는 않습니다.

  • 488 Not Acceptable Here
    Request-URI에 명기된 특정 자원이나 코덱을 사용할 수 없음을 의미합니다. 

  • 491 Request Pending
    UAS는 같은 다이얼로그안에 펜딩된 요청을 가지고 있음을 의미합니다.

  • 493 Undecipherable
    Request에 암호화된 MIME 바디를 포함하고 있어 처리할 수 없음을 의미합니다. 


5. 5xx Server Error
서버  자체가 에러가 발생하여 요청을 처리할 수 없을 때 사용합니다. 

  • 500 Server Internal Error
    요청을를 처리 중에 서버 내부 문제로 인해 처리할 수 없음을 의미합니다. 

  • 501 Not Implemented
    요청을 처리하기 위한 서비스나 기능이 서버에서 지원되지 않음을 의미합니다. 

  • 502 Bad Gateway
    게이트웨이나 Proxy서버가 잘못된 응답을 다른 서버로 부터 받았음을 의미합니다.

  • 503 Service Unavailable
    서버는 일시적인 과부하나 유지보수로 인해 요청을 처리할 수 없음을 의미합니다. 서버는 Retry-After 헤더를 포함하여 응답합니다. 클라이언트가 Request를 다른 서버로 재전송할 수 있습니다.

  • 504 Server Time-out
    서버는 외부 서버로 부터 정해진 시간 내에 응답을 받지 못했음을 의미합니다. 

  • 505 Version Not Supported
    서버는 SIP 프로토콜 버전을 지원하지 않음을 의미합니다.  

  • 513 Message Too Long
    서버는 요청의 메세지의 길이 너무 길어 처리할 수 없음을 의미합니다.

6. 6xx Global Failures
서버는 특정 사용자에 대한 최종 정보를 가지고 있다는 것을 의미합니다.

  • 600 Busy Everywhere
    상대방의 단말에 연결되었지만, 상대방이 바쁘거나 전화를 받지 않아 통화할 수 없음을 의미합니다. 

  • 603 Decline
    상대방의 단말에 연결되었지만, 상대방은 통화를 원하지 않음을 의미합니다. 

  • 604 Does Not Exist Anywhre
    Request-URI에 나타난 사용자가 존재하지 않음을 의미합니다. 

  • 606 Not Acceptable
    상대방에게 연결되었지만, 요청된 미디어나 대역폭 등의 이유로 연결할 수 없음을 의미합니다.

7. SIP Error Response 따른 SIP 동작들 
지금까지 설명한 응답들은 RFC 3261를 기준으로 설명하였으므로 RFC 3261의 "21 Response Codes"에 자세히 나와 있습니다. 실제 SIP 패킷 분석을 통한 장애처리 시에 참조하시기 바랍니다. 


지금까지 설명한 응답 상황에 따른 호절차를 간단히 살펴보겠습니다. 

  • Redirect : 302 “Moved Temporarily”
    엘리스가 밥의 데스크탑 전화기로 INVITE 요청을 한 경우입니다. 밥의 전화기는 오프라인 상태이거나 착신 번호 변경 설정을 한 상태로 가정할 수 있습니다. 이때 INVITE 요청에 대한 302 "Moved Temporarily" 응답이 Redirect Server에 의해 전송됩니다. 이 때 302 Response 내의 Contact 헤더는 re-INVITE를 전송할 주소가 명기되고 re-INVITE 가 밥의 소프트폰으로 전송됩니다.




    일반적으로 Redirect Server 는 SIP Proxy와 함께 구현이 됩니다. 만일 착신전환(Call Forward All)을 설정하였으나 SIP Proxy내의 밥의 프로파일에 설정 변경이 이루어지지 않고 전화기에서만 구현하였다면 아래 그림과 같이 전화기에서 302 “Moved Temporarily”를 발행합니다.  



    실제 호 절차는 SIP Proxy에 의해 이루어지나 Bob의 전화기에 의해 발생합니다. 착신전환은 가장 많이 사용하는 서비스입니다. 착신전환을 구현하는 방식은 제조사마다 다양합니다. IP PBX와 전화기를 같이 제조하는 회사는 IP PBX의 사용자 프로파일을 변경하여 설정할 수 있지만, 전화기만을 만드는 회사는 전화기에서 처리하는 방식을 선택하거나 특정 IP PBX에서만 동작할 수 있도록 구현합니다. 

    실제 전화기에 하는 방법은 보안에 매우 취약하므로 선호되지는 않습니다.
     


  • Unsupported Codec : 488 Not Acceptable Here
    엘리스는 G.711로 호를 개통하기 위해 INVITE 요청을 밥에게 보내지만, 밥은 G.729만을 지원합니다. 이 때 488 "Not Acceptable Here"라고 응답하면서 밥이 선호하는 코덱을 SDP 메세지 바디에 명기합니다. 엘리스는 G.729로 통화하자고re-INVITE를 보냅니다.  

     
  • Called Party Busy : 486 Busy Here
    밥은 현재 데이브와 통화중이지만, SIP Proxy가 밥의 상태를 인지하지 못해 INVITE를 밥에게 전달합니다. 밥은 "486 Busy Here" 에러로 응답합니다. 



    여기에서는 통화중일 경우를 가정하여 설명했지만, UAS (착신측 UA)가 호를 진행할 수 없는 모든 상황에 대해 보낼수 있습니다. 

    비슷한 응답으로 600 Busy Everywhere 와 488 Not Acceptable Here 도 가능합니다. UAS가 호를 응답할 수 있는 다른 시스템이 없을 경우는 600 에러를 발행하고, UAS가 호를 거절할 경우 488 에러가 발행됩니다. 488 에러는 정확한 거절사유가 명기되어야 합니다.
     


  • Call Forward Busy : 181 Call Forwarded
    통화중인 밥으로 부터 486 “Busy Here”를 수신한 SIP Proxy 서버는 밥의 프로파일에 설정된 Call Forward Busy 전화번호로 INVITE를 발행하고, 앨리스에게 181 “Call Forwarded”라는 정보를 보내줍니다.




  • Gateway Congestion : 503 Service Unavailable
    INVITE를 수신한 게이트웨이는 충분한 리소스가 없으므로 503 "Service Unavailable"로 응답합니다. SIP Proxy 서버는 로드밸런싱 매커니즘에 의해 두번째 게이트웨이로 다시 호를 시도하여 통화를 성공시킵니다.  이런 프로세스가 진행될 수 있도록 SIP Proxy서버에 설정되어 있어야 합니다






마치며
RFC 3261에 설명된 요청과 응답을 중심으로 설명하였습니다. 개발자는 이외에 SIP의 동작방식과 더 많은 SIP 헤더를 알아야 하므로 RFC 3261를 깊게 공부해야 겠지만, 엔지니어는 이 정도의 내용만 알고 있어도 SIP 장애 처리나 상호연동에 큰 도움이 될 것입니다. 

다음 장부터는 RFC 3261 를 벗어나 보겠습니다.






"다시쓰는 SIP의 이해" 연재의 다른 글  


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method


2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method


2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method


2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method


2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method


2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method


2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method


2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method

2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP


2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP


2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP


2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response


2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261


2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261


2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261


2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview


2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview


2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)


2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)


2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)




라인하
트 유씨누스 (CCIEV #18487)
  --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ______________________________________________



저작자 표시 비영리
신고
Posted by 라인하트
TAG ,

댓글을 달아 주세요

  1. 방랑자 2014.12.17 09:44 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 라인하트님..

    예전에 SIP의 이해보면서 질문했던 사람입니다.ㅎ

    덕분에 SIP에 많은 지식을 얻었습니다..

    다시 SIP 연재를 하시더라구요 ..ㅎㅎ

    그래서 질문드리는데 이번 연재글도 PDF화 시키시나해서요 ..ㅎㅎ

  2. 방랑자 2014.12.17 19:57 신고  댓글주소  수정/삭제  댓글쓰기

    ㅎㅎ 알겠습니다..!!

    연재가 끝나시면 pdf로 만들어볼게요!

  3. 골드만 삭스 2015.08.07 13:26 신고  댓글주소  수정/삭제  댓글쓰기

    항상 좋은 자료 감사드립니다.



티스토리 툴바