SIP 응답 코드 목록
List of SIP response codesSIP(Session Initiation Protocol)는 Voice over IP 전화 통화와 같은 통신 세션을 제어하는 데 사용되는 신호 전달 프로토콜이다. SIP는 요청/응답 트랜잭션을 기반으로 하며, HTTP(Hypertext Transfer Protocol)와 유사한 방식으로 한다. 각 거래는 SIP 요청(여러 요청 방법 중 하나가 될 것)과 적어도 하나의 응답으로 구성된다.[1]: p11
SIP 요청 및 응답은 SIP 사용자 에이전트에 의해 생성될 수 있으며, 사용자 에이전트는 요청을 시작하는 클라이언트(UAC)와 이에 응답하는 서버(UASes)로 구분된다.[1]: §8 단일 사용자 에이전트는 서로 다른 트랜잭션에 대해 UAC와 UAS 역할을 모두 수행할 수 있다.[1]: p26 예를 들어, SIP 전화는 통화할 때 UAC가 되는 사용자 에이전트 및 수신할 때 UAS가 될 사용자 에이전트다. 또한, 일부 장치는 단일 트랜잭션에서 UAC와 UAS 역할을 모두 수행할 것이다. 이를 B2BUA(Back-to-Back User Agents)라고 한다.[1]: p20
SIP 응답은 세 자리 정수 응답 코드를 지정하는데, 이는 요청의 상태를 상세히 기술하는 다수의 정의된 코드 중 하나이다. 이러한 코드는 첫 번째 숫자에 따라 1-6의 첫 번째 숫자에 해당하는 "provision", "success", "redirection", "클라이언트 오류", "서버 오류" 또는 "global failure" 코드로 그룹화되며, 예를 들어 100–199의 잠정 응답에 대한 "xx"로 표현된다.[1]: §7.2 모든 HTTP 응답 코드가 SIP에서 유효한 것은 아니지만 SIP 응답 코드는 HTTP 응답 코드와 일치한다.[1]: §21
또한 SIP 응답은 "이유 구문"을 명시하고, 기본 사유 구문은 각 응답 코드로 정의된다.[1]: §7.2 그러나 이러한 이유 구문은 추가 정보를[1]: §21.4.18 제공하거나 텍스트를 다른 언어로 제공하는 등 다양할 수 있다.[1]: §20.3
SIP 응답 코드와 해당 이유 구문은 처음에 RFC 3261에 정의되었다.[1] 또한 RFC는 다른 RFC가 더 많은 응답 코드를 제공할 수 있도록 SIP 매개변수 IANA(Internet Assigned Numbers Authority) 레지스트리를 정의한다.[1]: §27 [2]
이 목록은 2017년[update] 7월 14일 현재 IETF RFCs에 정의되고 SIP 매개변수 IANA 레지스트리에 등록된 모든 SIP 응답 코드를 포함한다. 또한 이 목록은 IANA에 등록되지 않은 구식 SIP RFCs(특히 RFC 2543)에 정의된 SIP 응답 코드도 포함한다. 이러한 코드들은 명시적으로 다음과 같이 언급된다.
1xx - 프로비저닝 응답
- 100 트라이닝
- 확장 검색 수행은 상당한 시간이 걸릴 수 있으므로, 포킹 프록시는 100 Trying 응답을 보내야 한다.[1]: §21.1.1
- 180 링잉
- 대상 사용자 에이전트가 초대를 받았으며 사용자에게 호출 알림입니다.[1]: §21.1.2
- 181 호 전달 중
- 서버는 이 응답을 선택적으로 보내 통화가 전달되고 있음을 나타낼 수 있다.[1]: §21.1.3
- 182 대기열
- 대상을 일시적으로 사용할 수 없었으므로 서버가 대상을 사용할 수 있을 때까지 호출을 대기열에 넣었음을 나타낸다. 서버는 대기열의 진행 상황을 업데이트하기 위해 182개의 응답을 보낼 수 있다.[1]: §21.1.4
- 183 세션 진행률
- 이 응답은 아직 설정 중인 통화에 대한 추가 정보를 보내는 데 사용될 수 있다.[1]: §21.1.5
- 199 조기 대화 종료됨
- User Agent Server가 업스트림 SIP 엔티티(User Agent Client(UAC) 포함)에 초기 대화 상자가 종료되었음을 알리는 데 사용할 수 있다.[3]
2xx - 성공적인 응답
- 200 OK
- 요청이 성공했음을 나타낸다.[1]: §21.2.1
- 202 수락됨
- 처리를 위해 요청이 수락되었지만 처리가 완료되지 않았음을 나타낸다.[4]: §7.3.1 [5] 사용되지 않음.[6]: §8.3.1 [2]
- 204 알림 없음
- 요청이 성공했음을 나타내지만 해당 응답이 수신되지 않는다.[7]
3xx - 재방향 응답
- 300개의 다양한 선택 사항
- 메시지 본문 또는 메시지의 연락처 필드에 나열된 사용자 또는 클라이언트가 선택할 수 있는 여러 옵션 중 하나로 확인된 주소.[1]: §21.3.1
- 301 영구적으로 이동됨
- 원래의 Request-URI는 더 이상 유효하지 않으며, 새 주소는 Contact 헤더 필드에 제공되며, 클라이언트는 원래 Request-URI의 레코드를 새 값으로 업데이트해야 한다.[1]: §21.3.2
- 302 임시 이동
- 클라이언트는 연락처 필드의 주소에서 시도해야 한다. 만료 필드가 있는 경우, 클라이언트는 해당 기간 동안 결과를 캐시할 수 있다.[1]: §21.3.3
- 305 프록시 사용
- 연락처 필드는 요청된 대상에 액세스하는 데 사용해야 하는 프록시를 자세히 설명한다.[1]: §21.3.4
- 380 대체 서비스
- 통화는 실패했지만 메시지 본문에 대안이 자세히 적혀 있다.[1]: §21.3.5
4xx - 클라이언트 오류 응답
- 400 불량 요청
- 구문이 잘못되어 요청을 이해할 수 없었다.[1]: §21.4.1
- 401 승인되지 않음
- 이 요청은 사용자 인증을 필요로 한다. 이 대응은 UAS와 등록기관에 의해 발표된다.[1]: §21.4.2
- 402 결제 필요
- 나중에 사용할 수 있도록 예약됨.[1]: §21.4.3
- 403 금지됨
- 서버는 그 요청을 이해했지만, 그것을 이행하기를 거부하고 있다.[1]: §21.4.4 때때로 (하지만 항상은 아님) 이것은 전화가 수신자에 의해 거부되었다는 것을 의미한다.
- 404 찾을 수 없음
- 서버는 사용자가 Request-URI에 지정된 도메인에 존재하지 않는다는 확정 정보를 가지고 있다. 요청-URI의 도메인이 요청 수신인이 처리한 도메인 중 하나와 일치하지 않는 경우에도 이 상태가 반환된다.[1]: §21.4.5
- 405 메서드는 허용되지 않음
- Request-Line에 지정된 방법은 이해되지만 Request-URI로 식별된 주소에는 허용되지 않는다.[1]: §21.4.6
- 406 허용 안 됨
- 요청에 의해 식별된 자원은 요청에서 전송된 헤더 수락 필드에 따라 내용 특성은 있지만 수용할 수 없는 응답 엔터티만 생성할 수 있다.[1]: §21.4.7
- 407 프록시 인증 필요
- 이 요청은 사용자 인증을 필요로 한다. 이 응답은 대리점에 의해 발행된다.[1]: §21.4.8
- 408 요청 시간 초과
- 사용자를 제때 찾을 수 없음. 예를 들어, 서버가 사용자의 위치를 제때 결정할 수 없는 경우, 서버는 적절한 시간 내에 응답을 생성할 수 없었다. 고객은 나중에 수정 없이 요청을 반복할 수 있다. [1]: §21.4.9
- 409년 분쟁
- 사용자가 이미 등록되어 있음.[8]: §7.4.10 이후 RFC에서[1] 누락되거나 IANA에 등록되지 않음으로 인해 더 이상 사용되지 않음.[2]
- 410년 사라짐
- 사용자는 한 번 존재했지만 더 이상 여기에서 사용할 수 없다.[1]: §21.4.10
- 411 필요한 길이
- 서버는 유효한 Content-Length 없이 요청을 수락하지 않는다.[8]: §7.4.12 이후 RFC에서[1] 누락되거나 IANA에 등록되지 않음으로 인해 더 이상 사용되지 않음.[2]
- 412 조건부 요청 실패
- 주어진 전제조건이 충족되지 않았다.[9]
- 413 요청 엔터티가 너무 큼
- 요청 본체가 너무 [1]: §21.4.11 큼
- 414 Request-URI 너무 길다
- Request-URI가 서버가 해석할 수 있는 것보다 길기 때문에 서버가 요청 서비스를 거부하는 경우.[1]: §21.4.12
- 415 지원되지 않는 미디어 유형
- 지원되지 않는 형식의 요청 [1]: §21.4.13 본문
- 416 지원되지 않는 URI 구성표
- Request-URI를 서버에서 알 수 없음.[1]: §21.4.14
- 417 알 수 없는 리소스 우선 순위
- 리소스 우선 옵션 태그가 있었지만 리소스 우선 순위 헤더는 없었다.[10]
- 420 배드 익스텐션
- 서버가 이해하지 못하는 잘못된 SIP 프로토콜 확장 사용.[1]: §21.4.15
- 421 확장 필요
- 서버가 지원되는 헤더에 나열되지 않은 특정 확장명을 필요로 하는 경우.[1]: §21.4.16
- 422 세션 간격이 너무 작음
- 수신된 요청에는 최소 타이머 미만의 지속 시간이 있는 세션 확장 헤더 필드가 포함되어 있다.[11]
- 423 간격이 너무 짧음
- 리소스의 만료 시간이 너무 짧다.[1]: §21.4.17
- 424 잘못된 위치 정보
- 요청의 위치 콘텐츠 형식이 잘못되었거나 만족스럽지 못한 경우.[12]
- 425 잘못된 경고 메시지
- 서버는 비상사태에 대한 합리적인 비상대응을 결정할 수 없을 정도로 요청이 기형적이었음을 나타내며 비상호 비상호출을 거부하였다.[13]
- 428 ID 헤더 사용
- 서버 정책에는 ID 헤더가 필요하며, 하나는 제공되지 않았다.[14]: p11
- 429 레퍼러 ID 제공
- 서버가 요청 시 유효한 참조별 토큰을 수신하지 [15]못함
- 430 흐름 실패
- 다른 흐름은 성공할 수 있지만 사용자 에이전트에 대한 특정 흐름은 실패하였다. 이 응답은 프록시 장치 간에 사용하기 위한 것이며 엔드포인트에서 볼 수 없어야 한다(하나에서 볼 경우 400 Bad Request 응답으로 간주해야 함).[16]: §11.5
- 433 익명성 허용되지 않음
- 그 요청은 익명으로 거절당했다.[17]
- 436 잘못된 ID-인포
- 요청에는 ID-Info 헤더가 있으며, 해당 헤더의 URI 체계는 참조 해제할 수 없다.[14]: p11
- 437 지원되지 않는 인증서
- 서버가 요청을 서명한 도메인에 대한 인증서를 검증할 수 없음.[14]: p11
- 438 잘못된 ID 헤더
- 서버는 요청 서명에 사용된 요청이 유효한 인증서를 얻었지만, 서명을 확인할 수 없었다.[14]: p12
- 439 퍼스트 홉 아웃바운드 지원 부족
- 사용자가 등록하려고 시도하는 첫 번째 아웃바운드 프록시는 등록자가 등록하지만 RFC 5626의 "아웃바운드" 기능을 지원하지 않는다.[16]: §11.6
- 440 Max-Breadth 초과
- SIP 프록시가 원하는 병렬 포크를 수행하기에 응답 컨텍스트가 불충분하고 프록시가 직렬로 요청하거나 리디렉션을 전송하여 보상할 의사가 없거나 불가능한 경우, 해당 프록시는 반드시 440개의 응답을 반환해야 한다. 440 회신을 받은 고객은 그 요청이 가능한 모든 목적지에 도달하지 않았음을 유추할 수 있다. [18]
- 469 잘못된 정보 패키지
- 만일 SIP UA가 UA가 수신 의사를 표시하지 않은 Info Package와 관련된 Info 요청을 수신할 경우, UA는 반드시 469 회신을 보내야 하며, 여기에는 UA가 INFO 요청을 수신할 의향이 있는 Info Package와 함께 Recv-Info 헤더 필드가 포함된다. [19]
- 470 동의 필요
- 요청의 출처에는 수령인의 허가가 없어서 그런 요청을 할 수 없었다.[20]
- 480 일시적으로 사용할 수 없음
- 현재 Callee를 사용할 수 없음.[1]: §21.4.18
- 481 통화/거래가 존재하지 않음
- 서버는 어떤 대화 상자나 트랜잭션과도 일치하지 않는 요청을 수신했다.[1]: §21.4.19
- 482 루프가 탐지됨
- 서버가 루프를 감지했다.[1]: §21.4.20
- 483 너무 많은 홉
- Max-Forwards 헤더가 '0'[1]: §21.4.21 값에 도달했다.
- 484 주소 불완전
- 요청-URI가 불완전함.[1]: §21.4.22
- 485 모호함
- 요청-URI가 애매하다.[1]: §21.4.23
- 486 이곳에서 바쁜 나날
- 칼리는 바쁘다.[1]: §21.4.24
- 487 요청 종료됨
- 요청이 종료 또는 취소로 종료됨.[1]: §21.4.25
- 488 여기서 허용되지 않음
- 세션 설명 또는 요청-URI의 일부 측면은 허용되지 않는다.[1]: §21.4.26
- 489 나쁜 사건
- 서버가 이벤트 헤더 필드에 지정된 이벤트 패키지를 이해하지 [4]: §7.3.2 [6]: §8.3.2 못함
- 491 요청 보류 중
- 서버에는 동일한 대화상자에서 보류 중인 요청이 있다.[1]: §21.4.27
- 493 해독할 수 없는
- 요청에는 수신인이 해독할 수 없는 암호화된 MIME 본문이 포함되어 있다.[1]: §21.4.28
- 494 보안 계약 필요
- 서버는 협상된 보안 메커니즘을 필요로 하는 요청을 받았으며, 응답에는 요청자가 선택할 수 있는 적절한 보안 메커니즘의 목록이나 [21]: §§2.3.1–2.3.2 다이제스트 인증 난제를 포함하고 있다.[21]: §2.4
5xx - 서버 오류 응답
- 500 내부 서버 오류
- 서버가 예기치 않은 상황으로 인해 요청을 처리할 수 없었다.[1]: §21.5.1
- 501 미실행
- 서버가 요청 방법을 인식하지 못하는 등 요청을 이행할 수 있는 능력이 없다.(서버가 방법을 인식하지만 허용 또는 지원하지 않는 405 Method Not Allow와 비교)[1]: §21.5.2
- 502 잘못된 게이트웨이
- 서버가 게이트웨이 또는 프록시 역할을 하고 있으며, 요청을 이행하려고 시도하는 동안 다운스트림 서버로부터 잘못된 응답을 받았다.[1]: §21.5.3
- 503 서비스를 사용할 수 없음
- 서버가 유지보수 중이거나 일시적으로 오버로드되어 요청을 처리할 수 없는 경우. "Retry-After" 헤더 필드는 클라이언트가 요청을 재시도할 수 있는 시기를 지정할 수 있다.[1]: §21.5.4
- 504 서버 시간 초과
- 서버가 요청을 처리할 때 다른 서버에 액세스를 시도했지만, 신속한 응답을 받지 못했다.[1]: §21.5.5
- 505 버전이 지원되지 않음
- 요청의 SIP 프로토콜 버전은 서버에서 지원되지 않는다.[1]: §21.5.6
- 513 메시지가 너무 큼
- 요청 메시지 길이가 서버가 처리할 수 있는 길이보다 길다.[1]: §21.5.7
- 555 푸시 알림 서비스 지원되지 않음
- 서버가 'pn-provider' SIP URI 매개[22]: §14.2.1 변수에 식별된 푸시 알림 서비스를 지원하지 않음
- 580 전제 조건의 고장
- 서버는 오퍼에 명시된 제약을 충족시킬 수 없거나 충족하기를 원하지 않는다.[23]
6xx - 글로벌 오류 응답
- 어디에나 바쁜 600명
- 가능한 모든 목적지가 분주하다. 486 응답과는 달리, 이 응답은 전화를 받을 수 있는 대체 수신처(예: 음성 메일 서버)가 없다는 것을 목적지가 알고 있음을 나타낸다.[1]: §21.6.1
- 603 사양
- 목적지는 통화에 참여하기를 원하지 않거나 참여할 수 없으며, 또한 목적지에는 통화에 기꺼이 응할 수 있는 다른 목적지(예: 음성 메일 서버)가 없다는 것을 알고 있다.[1]: §21.6.2 응답은 재시도-후 헤더 필드를 호출하기에 더 좋은 시간을 나타낼 수 있다.
- 604 어디에도 존재하지 않음
- 서버는 요청된 사용자가 존재하지 않는다는 신뢰할 수 있는 정보를 가지고 있다.[1]: §21.6.3
- 606 허용 안 됨
- 사용자의 에이전트가 성공적으로 연결되었지만 요청된 미디어, 대역폭 또는 주소 지정 스타일과 같은 세션 설명의 일부 측면은 허용되지 않았다.[1]: §21.6.4
- 607 원하지 않음
- 소집된 일행은 소집단으로부터 이 전화를 받고 싶지 않았다. 향후 통화당국의 시도도 마찬가지로 거부될 가능성이 높다.[24]
- 608 거부됨
- 중개 기계 또는 프로세스가 통화 시도를 거부함.[25] 이는 607(무원) SIP 응답 코드와 대비된다. 통화를 거부하는 중개인은 연락처 세부 정보가 포함된[26] jCard를 포함하며, 거부 시 이의를 제기할 경우 통화 당사자가 사용할 수 있다. 응답에는 다음을 포함하는 콜-인포 헤더에서 호출을 차단한 접촉 실체가 포함될 수 있다.
참조
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj bk Rosenberg, Jonathan; Schulzrinne, Henning; Camarillo, Gonzalo; Johnston, Alan; Peterson, Jon; Sparks, Robert; Handley, Mark; Schooler, Eve (June 2002). SIP: Session Initiation Protocol. IETF. doi:10.17487/RFC3261. RFC 3261.
- ^ a b c d Roach, Adam; Jennings, Cullen; Peterson, Jon; Barnes, Mary (17 April 2013) [Created January 2002]. "Response Codes". Session Initiation Protocol (SIP) Parameters. IANA.
- ^ Holmberg, Christer (May 2011). Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. IETF. p. 1. Abstract. doi:10.17487/RFC6228. RFC 6228.
- ^ a b Roach, Adam B. (June 2002). Session Initiation Protocol (SIP)-Specific Event Notification. IETF. doi:10.17487/RFC3265. RFC 3265.
- ^ Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (June 1999). "202 Accepted". Hypertext Transfer Protocol -- HTTP/1.1. IETF. sec. 10.2.3. doi:10.17487/RFC2616. RFC 2616.
- ^ a b Roach, Adam (July 2012). SIP-Specific Event Notification. IETF. doi:10.17487/RFC6665. RFC 6665.
- ^ Niemi, Aki (May 2010). "204 (No Notification) Response Code". In Willis, Dean (ed.). An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification. IETF. sec. 7.1. doi:10.17487/RFC5839. RFC 5839.
- ^ a b Handley, Mark; Schulzrinne, Henning; Schooler, Eve; Rosenberg, Jonathan (March 1999). SIP: Session Initiation Protocol. IETF. doi:10.17487/RFC2543. RFC 2543.
- ^ Niemi, Aki, ed. (2004). ""412 Conditional Requset Failed" Response Code". Session Initiation Protocol (SIP) Extension for Event State Publication. IETF. sec. 11.2.1. doi:10.17487/RFC3903. RFC 3903.
- ^ Schulzrinne, Henning; Polk, James (February 2006). "No Known Namespace or Priority Value". Communications Resource Priority for the Session Initiation Protocol (SIP). IETF. sec. 4.6.2. doi:10.17487/RFC4412. RFC 4412.
- ^ Donovan, Steve; Rosenberg, Jonathan (April 2005). "422 Response Code Definition". Session Timers in the Session Initiation Protocol (SIP). IETF. sec. 6. doi:10.17487/RFC4028. RFC 4028.
- ^ Polk, James; Rosen, Brian; Peterson, Jon (December 2011). "424 (Bad Location Information) Response Code". Location Conveyance for the Session Initiation Protocol. IETF. sec. 4.3. doi:10.17487/RFC6442. RFC 6442.
- ^ Rosen, Brian; Schulzrinne, Henning; Tschofenig, Hannes; Gellens, Randall (September 2020). "425 (Bad Alert Message) Response Code". Non-interactive Emergency Calls. IETF. sec. 5.1. doi:10.17487/RFC8876. RFC 8876.
- ^ a b c d Peterson, Jon; Jennings, Cullen (August 2006). Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC4474. RFC 4474.
- ^ Sparks, Robert J. (September 2004). "The 429 Provide Referrer Identity Error Response". The Session Initiation Protocol (SIP) Referred-By Mechanism. IETF. sec. 5. doi:10.17487/RFC3892. RFC 3892.
- ^ a b Jennings, Cullen; Mahy, Rohan; Audet, Francois, eds. (October 2009). Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC5626. RFC 5626.
- ^ Rosenberg, Jonathan (December 2007). "433 (Anonymity Disallowed) Definition". Rejecting Anonymous Requests in the Session Initiation Protocol (SIP). IETF. sec. 5. doi:10.17487/RFC5079. RFC 5079.
- ^ Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. IETF. December 2008. doi:10.17487/RFC5393. RFC 5393.
- ^ Session Initiation Protocol (SIP) INFO Method and Package Framework. IETF. January 2011. doi:10.17487/RFC6086. RFC 6086.
- ^ Rosenberg, Jonathan; Willis, Dean (October 2008). "Definition of the 470 Response Code". In Camarillo, Gonzalo (ed.). A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP). IETF. sec. 5.9.2. doi:10.17487/RFC5360. RFC 5360.
- ^ a b Arkko, Jari; Torvinen, Vesa; Camarillo, Gonzalo; Niemi, Aki; Haukka, Tao (January 2003). Security Mechanism Agreement for the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3329. RFC 3329.
- ^ Push Notification with the Session Initiation Protocol (SIP). IETF. May 2019. doi:10.17487/RFC8599. RFC 8599.
- ^ Rosenberg, Jonathan (October 2002). "Refusing an offer". In Camarillo, Gonzalo; Marshall, Bill (eds.). Integration of Resource Management and Session Initiation Protocol (SIP). IETF. sec. 8. doi:10.17487/RFC3312. RFC 3312.
- ^ A SIP Response Code for Unwanted Calls. IETF. July 2017. doi:10.17487/RFC8197. RFC 8197.
- ^ A Session Initiation Protocol (SIP) Response Code for Rejected Calls. IETF. December 2019. doi:10.17487/RFC8688. RFC 8688.
- ^ RFC 7095
외부 링크
- SIP 오류 메시지를 DSS1 코드에 매핑
- SIP(Session Initiation Protocol) 매개변수 응답 코드를 포함하여 서로 다른 SIP 매개변수의 레지스트리 포함