[RFC 3261] CHAPTER 13. Initiating a Session

CHAPTER 13. Initiating a Session

(13.1) Overview

해당 13절에서는 INVITE를 사용한 세션 생성 절차를 설명한다.
INVITE를 지원하는 UA는 ACK, CANCEL, BYE도 지원해야 한다. (MUST)

 

UAC는 세션을 시작하고자 할 때 INVITE request를 생성하여 서버에게 세션 설정을 요청한다.

• INVITE는 프록시를 통해 전달되다가 하나 이상의 UAS에 도달한다.
  → SIP 라우팅 특성상 request는 forking으로 하나의 INVITE가 여러 대상에게 전달될 수 있음
• UAS는 사용자에게 수신 화면을 띄우는 등 처리를 통해 세션 수락 여부를 확인한다.
• UAS는 final response 전송 전, 먼저 provisional response(1xx)를 보내 UAC에게 진행 상황을 알릴 수 있다.
• UAC는 provisional response(예: 180 Ringing)를 여러 개 받을 수 있다.
• 이후 UAS는 상황에 따라 다음 중 하나의 final response를 전송한다.
  • 2xx response: 세션 수락
  • non-2xx final response(3xx~6xx): 세션 거절 또는 실패 사유 반환

응답 종류	설명	예시 코드
Provisional Response	최종 응답 전 상태를 알리는 임시 응답	100 Trying, 180 Ringing, 183 Session Progress
Non-Failure Final Response	세션이 성공적으로 처리되었거나 리디렉션된 최종 응답	200 OK
❌ Failure Final Response	세션이 실패했음을 알리는 최종 응답	403 Forbidden, 486 Busy Here
Final Response	non-failure 또는 failure 응답을 포함한 최종 응답 전체 범주	2xx, 3xx, 4xx, 5xx, 6xx → 1xx 제외

INVITE에 대한 final response 수신까지 오래 걸릴 수 있기 때문에(=전화 받을 때까지) INVITE 트랜잭션의 신뢰성 메커니즘은 다른 request(예: OPTIONS)의 메커니즘과 다르다.

→ 일반적인 request(예: OPTIONS, BYE)는 비교적 response를 빠르게 받음

→ INVITE는 지연될 수 있기에 별도의 신뢰성 처리

 

UAC는 INVITE 트랜잭션의 final response에 대해 ACK를 보내야 한다. 전송 방식은 response 유형에 따라 다르다.

• 2xx response: UAC core에서 직접 ACK 생성
• 300~699 response: 트랜잭션 계층에서 ACK 처리 (17절 참고)

 

INVITE에 대한 2xx response는 세션을 설정하고, INVITE를 보낸 UA와 2xx response를 보낸 UA 사이에 dialog를 생성한다.

• INVITE가 fork된 경우, 여러 개의 UAS로부터 2xx response를 받을 수 있으며, 각각 별도의 dialog가 생성된다.
• 이 dialog 들은 모두 동일한 call에 속하게 된다.

 

(13.2) UAC Processing

(13.2.1) Creating the Initial INVITE

Initial INVITE는 dialog가 형성되지 않은 상태에서의 request이므로, (8.1.1절 - Generating the Request) 절차를 따르며, 추가적으로 INVITE에 특화된 절차도 필요하다. 다음 헤더들은 INVITE와 관련된 정보를 포함한다.

 

INVITE에는 Allow 헤더 필드(20.5절 참고)를 포함해야 한다. (SHOULD)

• dialog가 진행되는 동안 INVITE를 보낸 UA가 지원하는 메소드 목록을 나타낸다.
• 예: INVITE, ACK, OPTIONS, CANCEL, BYE

20.5 Allow

- Allow 헤더 필드는 해당 메시지를 생성한 UA가 지원하는 메소드들의 목록을 명시한다.
- Allow 헤더 필드가 존재한다면, UA가 이해할 수 있는 모든 메소드(ACK, CANCEL 포함)는 반드시 목록에 포함되어야 한다.
- Allow 헤더 필드가 없다고 해서, 해당 UA가 아무 메소드도 지원하지 않는다는 뜻으로 해석하면 안된다. 단지, 지원하는 메소드에 대한 정보를 제공하지 않았을 뿐이라는 뜻이다.
- OPTIONS 메소드 외의 요청에 Allow 헤더 필드를 포함시키면, 필요한 메시지 수를 줄일 수 있다.

 

 

INVITE에는 Supported 헤더 필드(20.37절 참고)를 포함해야 한다. (SHOULD)

• UAC가 지원하는 확장 기능 목록을 나열한다.

 

INVITE에는 Accept 헤더 필드(20.1절 참고)를 선택적으로 포함할 수 있다. (MAY)

• Subsequent request에서 UA가 지원하는 Content-Type을 지정한다.
• 예: Accept: application/sdp

 

UAC는 INVITE의 유효 시간을 제한하기 위해 Expires 헤더 필드(20.19 참고)를 추가할 수 있다. (MAY)

• 유효 시간동안 INVITE에 대한 final response를 받지 못하면, UAC core는 CANCEL request를 생성해야 한다. (SHOULD) (9절 참고)

 

INVITE 메시지 body에는 SDP가 포함된다. 이때 Content-Disposition 헤더는 "session"으로 설정해야 한다.

→ Content-Disposition: session → 이 body는 세션 설정 목적이다 라는 뜻

 

SIP는 offer / answer 모델을 사용한다.

→ SDP를 이용해 한 쪽이 offer를 보내고, 다른 쪽이 answer로 응답하는 방식

• offer: UA가 session description을 send
  • 통신 수단(예: 오디오, 비디오) 관련 파라미터(예: 코덱 종류), 미디어 수신 주소 등을 명시한다.
• answer: UA가 session description을 respond
  • 수락한 통신 수단, 적용 가능한 파라미터, 미디어 수신 주소가 포함된다.

 

offer/answer 교환은 dialog context 내에서 이루어지며, 하나의 INVITE가 multiple dialog를 생성했다면, 각각 독립적인 offer/answer 교환이 이루어진다.

→ fork된 INVITE의 경우, 각각 개별 세션으로 설정되기 때문

• 진행중인 offer가 있으면 새 offer를 생성할 수 없다. → 동시에 두 개의 offer를 보낼 수 없다.
• RFC 3261에서 offer와 answer는 INVITE request, 2xx response, ACK request 에만 포함될 수 있다.

 

✅ Initial INVITE transaction의 offer / answer 규칙

INVITE를 지원하는 모든 UA는 아래 두 가지 offer/answer 방식을 반드시 지원해야 한다. (MUST)

 

✔ 첫 번째 방식 (가장 일반적)

• offer는 INVITE에 포함된다.
• answer는 2xx response에 포함된다.

→ INVITE (offer) → 180 Ringing (optional SDP) → 200 OK (answer)

 

✔ 두 번째 방식

• offer는 2xx response에 포함된다.
• answer는 그 2xx에 대한 ACK에 포함된다.

→ INVITE (no SDP) → 200 OK (offer) → ACK (answer)

 

RFC 3261에서 reliable non-failure message는 해당 INVITE에 대한 final 2xx response을 의미한다.

 

1. Initial offer는 반드시 다음 중 하나에 포함되어야 한다. (MUST)
   • INVITE request
   • UAS가 UAC에게 보내는 첫 번째 final 2xx response
2. INVITE에 offer가 포함되어 있다면, 그에 대한 answer는 해당 INVITE와 연관된 final 2xx response 에 반드시 있어야 한다.
   • UAC는 Initial INVITE에 대한 response 중 최초로 받은 session description을 answer로 간주해야 하며, 그 이후에 도착한 session description은 무시해야 한다. (MUST)
3. 반대로 initial offer가 첫 번째 final 2xx response에 포함되어 있다면, answer는 반드시 그에 대한 ACK에 있어야 한다. (MUST)
   → INVITE에 offer가 없고, UAS가 보내는 200 OK에 offer(SDP)가 들어있는 경우
4. Initial offer / answer 교환이 완료된 이후에만, UAC는 reqeust 안에 subsequent offer를 생성할 수 있다. (MAY)
   • 단, 어떤 request에 offer을 넣을 수 있는지는 각 request 메소드 규칙에 따른다.
     • BYE, CANCEL, OPTIONS에는 offer 넣으면 안 됨.
     • re-INVITE는 조건 만족 시 offer 포함 가능
   • 이전 offer에 대한 answer를 모두 받은 경우에만 가능하며, 아직 answer를 받지 못한 offer를 보낸 상태에서는 새로운 offer를 보내서는 안된다.
5. Initial offer / answer 교환이 완료되었다면, 그 이후에는 Initial INVITE 트랜잭션의 response에서 subsequent offer를 생성해서는 안된다. (MUST NOT)

 

모든 UA는 세션을 기술하기 위한 수단으로 Session Description Protocol (SDP)를 반드시 지원해야 한다. (MUST)
→ offer/answer 교환에서 세션 정보는 항상 SDP 포맷으로 표현해야 함.

• offer과 answer를 구성할 때 사용하는 방식은 (RFC 3254) 절차를 따라야 한다. (MUST)

 

offer/answer 모델의 제약 조건은 Content-Disposition 헤더 필드 값이 “session”인 body에만 적용된다.

따라서, INVITE와 ACK 둘 다 body를 가질 수 있으며, Content-Disposition 헤더가 생략된 경우,

• Content-Type이 application/sdp 이면 → 자동으로 “session”으로 간주
• 그 외의 Content-Type 이면→ "render"로 간주

→ body가 있다고 무조건 offer/answer 규칙이 적용되는게 아니다.

 

INVITE가 생성되면, UAC는 (8절 - dialog 외부에서의 request) 절차를 따라야 한다.

• 이 절차를 통해 UAC는 하나의 클라이언트 트랜잭션을 생성하게 되고, 그 트랜잭션이 request를 전송하고 response를 수신해서 UAC에 전달한다.

---

(13.2.2) Processing INVITE Responses

INVITE request가 INVITE 클라이언트 트랜잭션에게 전달되면, UAC는 해당 request에 대한 response를 기다린다. 클라이언트 트랜잭션이 response를 받지 못하고 timeout을 반환하면, TU는 408(Request Timeout) response를 수신한 것처럼 간주하고 처리해야 한다.

 

✅ (13.2.2.1) 1xx Responses

final reponse가 도착하기 전에 0개 이상의 provisional response(1xx)가 올 수 있다.

• INVITE에 대한 provisional response(1xx) 는 early dialog를 생성할 수 있다.
• provisional response(1xx)에 To tag가 있고, 그 response의 dialog ID가 기존 dialog와 일치하지 않는다면, (12.1.2절 - UAC dialog 생성) 절차를 따라 새로운 early dialog를 생성한다.

 

early dialog는 Initial INVITE 트랜잭션이 완료되기 전, UAC가 dialog 내에서 상대방에게 다른 request를 보내야 할 때만 필요하다.

• provisional response에 있는 헤더 필드들은 dialog가 early state일 때까지만 유효하다.
  (예: Allow 헤더는 early dialog 동안 허용되는 메서드들을 나타냄)

 

✅ (13.2.2.2) 3xx Responses

3xx resonse는 하나 이상의 Contact 헤더 필드 값을 제공할 수 있으며, callee(=수신자)를 대신 시도할 수 있는 새 주소들이 들어있다.

• UAC는 해당 3xx response 에 따라 선택적으로 새 주소들에 INVITE 재시도를 할 수 있다. (21.3절 참고) (MAY)

 

✅ (13.2.2.3) 4xx, 5xx and 6xx Responses

하나의 INVITE에 대해 하나 이상의 non-2xx final response를 받을 수 있다.

• 4xx, 5xx, 6xx response(= failure final)에는 Contact 헤더 필드 값이 포함될 수 있으며, 오류에 대한 추가 정보를 확인할 수 있는 위치(예: URL)가 들어 있을 수 있다.
• 그 이후 (오류 상황에서 발생할 수 있는) Subsequent final resonse는 반드시 무시해야 한다. (MUST)
  → 4xx response가 여러 개 온 경우, UAC는 가장 먼저 도착한 failure final response 1개만 처리해야함.

non-2xx final resopnse가 수신되면,

• 모든 early dialog는 종료된 것으로 간주한다.
• UAC core는 해당 INVITE 트랜잭션이 완료되었다고 간주한다.
• ACK 생성은 INVITE 클라이언트 트랜잭션이 처리한다. (17절 참고)

→ 성공 응답은 여러 개의 dialog를 만들 수 있으며, 각 dialog에 대해 독립된 ACK가 필요

→ UAC core는 failure response를 받아야만 상태를 정리하기에 ACK만 트랜잭션 레벨이 알아서 처리한다.

 

✅ (13.2.2.4) 2xx Responses

UAC는 forking proxy로 인해 하나의 INVITE에 대해 여러 개의 2xx response를 받을 수 있다.

• 각 resonse는 To tag(=remote tag)로 구별되며, 서로 다른 dialog를 나타낸다.

 

2xx response의 dialog ID가 기존 dialog와 일치한다면,

• 해당 dialog는 confirmed state로 전이되어야 하며, (MUST)
• route set는 해당 2xx response 정보를 기반으로 다시 계산되어야 한다. (12.2.1.2절 참고) (MUST)

2xx response의 dialog ID가 기존 dialog와 다르면,

• 새로운 dialog를 생성해야 하며, (MUST)
• 해당 dialog는 confirmed state에서 시작되어야 한다. (12.1.2절 참고) (MUST)

 

💬 다시 계산되는 것은 route set 뿐이며, dialog 전체 state는 갱신되지 않는다.
이는 early dialog 동안 mid-dialog request(예: UPDATE)로 인해 CSeq 번호 등이 변경되었을 수 있기 때문이다.

 

 

UAC core는 트랜잭션 계층으로부터 받은 각각의 2xx response마다 ACK request를 반드시 생성해야 한다.(MUST)
→ dialog를 기준으로 ACK를 생성해야 하기 때문에 TU가 전송

• ACK의 헤더 필드는 일반적인 dialog 내 request(12절)과 동일한 방식으로 구성한다. 단, CSeq 및 인증 관련 필드는 예외이다. (MUST)
  • CSeq 헤더는 INVITE의 CSeq 번호와 동일해야 하며, 메소드는 ACK여야 한다. (MUST)
  • ACK는 INVITE에 사용된 것과 동일한 인증 정보를 포함해야 한다. (MUST)
• 만약 2xx response에 offer가 포함되어 있다면, ACK body에는 반드시 answer가 포함되어야 한다. (MUST)
• 만약 2xx response에 포함된 offer가 수락할 수 없는 것이라면, UAC는 answer를 담은 ACK를 먼저 보낸 후, 즉시 BYE를 전송하여 세션을 종료해야 한다. (MUST)

 

ACK가 구성된 후에는, RFC 3262에 따라 전송 대상의 주소, 포트, 전송 프로토콜을 결정한 후, 클라이언트 트랜잭션을 거치지 않고 전송 계층에 직접 전달된다.

→ 왜냐하면, INVITE 트랜잭션은 이미 종료되었기 때문

• 따라서 ACK 재전송은 UAC core가 직접 처리해야 한다.
• ACK는 해당 ACK를 유발한 2xx response가 재전송될 때마다, 반드시 전송 계층에 다시 전달되어야 한다. (MUST)

 

UAC core는 첫 번째 2xx response를 수신한 후, 64*T1 초(= 32초)가 지나면, INVITE 트랜잭션이 완료되었다고 간주한다.

• 이 시간이 지나면, confirmed state로 전이되지 않은 모든 early dialog는 종료된 것으로 간주한다.
  • → 즉, 200 OK를 받지 못한 early dialog는 삭제 대상
• 이후에는 새로운 2xx response는 더 이상 도착하지 않는다고 본다.

 

만약 UAC가 INVITE에 대한 2xx response에 대해 ACK를 보낸 후, 그 dialog를 더 이상 유지하고 싶지 않다면, (15절) 절차에 따라 BYE request를 전송하여 세션을 종료해야 한다.

→ 하지만 실제로 세션을 유지하고 싶은 상대와만 dialog를 유지하고, 나머지와는 ACK 후 즉시 BYE를 보내라고 권장(SHOULD)

---

(13.3) UAS Processing

(13.3.1) Processing of the INVITE

UAS core는 트랜잭션 계층으로부터 INVITE request를 수신한다.

• UAS는 먼저 dialog 내부/외부에 관계없이, 8.2절의 UAS request 처리 기본 절차를 수행한다.
• 만약 위 절차가 response를 생성하지 않고 정상적으로 완료되었다면, UAS core는 다음 추가 처리 절차를 수행한다.

 

1. INVITE에 Expires 헤더가 있는 경우

• UAS core는 해당 Expires 값(초 단위)을 기준으로 타이머를 설정한다.
• 타이머가 만료되면, 해당 INVITE는 만료된 것으로 간주된다.
• 만약 UAS가 아직 final response를 생성하지 않은 상태에서 INVITE가 만료되었다면, 487 (Request Terminated) response를 전송해야 한다 (SHOULD)

2. request가 mid-dialog request인 경우

• 먼저 12절의 메소드 독립적인 처리 절차를 적용한다.
• 해당 request는 세션을 수정할 수도 있다. (14절 참고)

3. To tag가 있지만 dialog ID가 UAS에 존재하지 않는 경우

• 즉, request에 To tag는 있으나, 그 dialog ID가 UAS가 가진 어떤 dialog와도 일치하지 않는다면,
  → 이는 UAS가 crash 후 재시작된 상황, 혹은 request가 잘못 전달된 상황일 수 있다.(12.2.2절 참고)

 

이후 처리는 해당 INVITE가 dialog 외부 request 임을 전제로 한다.

• 즉, 이 INVITE는 새로운 세션을 설정하려는 목적으로 간주된다.

 

✅ INVITE에 session description이 포함된 경우

• UAS는 세션에 대한 offer를 받은 것으로 간주된다.
• dialog 외부 INVITE라도, 사용자가 이미 동일한 세션에 참여 중일 수 있음
  • 예: 동일한 사용자가 여러 참가자로부터 같은 회의 INVITE를 동시에 받는 경우
• 이런 경우, UAS는 session description의 식별자들을 이용해 중복 여부를 탐지할 수 있다. (MAY)
  • 예: SDP의 o= 필드에는 session ID 및 버전 번호가 포함됨
• 만약 사용자가 이미 해당 세션에 참여 중이고, session description도 바뀌지 않았다면,
  → 사용자에게 알리지 않고 조용히 INVITE를 수락할 수 있다. (MAY)
  → 즉, 2xx response를 무음 처리로 전송 가능

✅ INVITE에 session description이 없는 경우

• 이 경우는 UAC가 먼저 offer를 보내지 않고, UAS에게 offer를 먼저 제시해 달라고 요청한 상황이다.
  -> delayed offer 방식: UAS가 먼저 offer 전송
• UAS는 반드시 자신이 보낸 첫 번째 final 2xx response에 offer를 포함해야 한다. (MUST)

 

UAS는 INVITE에 대해 진행 중(progress), 수락(accept), 리다이렉트(redirect), 거절(reject)을 나타낼 수 있다.

• 해당 경우, UAS는 (8.2.6절 - response 생성) 절차대로 response를 구성해야 한다.

 

(13.3.1.1) Progress

✅ UAS가 INVITE를 즉시 수락할 수 없는 경우,

• UAC에게 진행 중(progress) 임을 알릴 수 있다.
  → 예: 전화가 울리는 중이라는 화면 표시 등
• 이러한 진행 알림은 provisional response(101~199)를 통해 수행된다.
• provisional response는 early dialog를 생성하며, (8.2.6)과 (12.1.1) 절차를 따른다.
• UAS는 동일한 dialog ID를 가진 provisional response를 원하는 만큼 여러 번 보낼 수 있다. (MAY)
• → 하지만 이러한 provisional response는 기본적으로 비신뢰적(unreliable) 이다.
  → 즉, UAC가 수신하지 못하더라도 재전송이 보장되지 않는다.

 

✅ UAS가 응답하기까지 시간이 오래 걸리는 경우

• 프록시가 INVITE 트랜잭션을 취소하지 않도록 “extension” 요청을 해야한다.
• 프록시는 일정 시간(예: 3분) 이상 response가 없을 경우, 트랜잭션을 CANCEL할 수 있다.
• 이를 방지하려면, response가 손실될 수 있는 가능성까지 고려하여 UAS는 최소 1분마다 100 Trying이 아닌 provisional response를 보내야 한다.

 

INVITE 트랜잭션은 다음과 같은 상황에서 장시간 지속 가능하다.

 

1. 사용자가 hold(보류) 상태일 때
→ final response 지연 가능

 

2. PSTN 시스템 연동 시

• call을 수신하지 않고도(=response 없이도) 통신이 가능한 구조를 허용하기 때문
• IVR 시스템에서 일반적으로 발생하는 사례

 

(13.3.1.2) The INVITE is Redirected

UAS가 call을 리다이렉션 하기로 결정하면 3xx response를 전송한다.

300 (Multiple Choices), 301 (Moved Permanently), 302 (Moved Temporarily) response는 하나 이상의 Contact 헤더를 포함해야 하며, UAC가 시도할 수 있는 URI가 담겨있어야 한다. (SHOULD)

• 해당 response는 INVITE 서버 트렌젝션에 전달되며, 해당 트랜잭션이 재전송을 처리한다.

 

(13.3.1.3) The INVITE is Rejected

✅ callee(수신자)가 해당 단말에서 추가적인 call을 받을 수 없거나, 거절하고자 할 경우

• UAS는 486(Busy Here) response를 반환해야 한다. (SHOULD)

✅ 수신자가 다른 단말(예: 여러 endpoint)에 등록되어 있지 않음을 UAS가 확실히 알고 있는 경우

• 대신 600 (Busy Everywhere) response를 보내야 한다. (SHOULD)
• 하지만 일반적으로 UAS가 이런 상황을 정확히 알 수 있는 경우는 드물기 때문에 600은 거의 사용되지 않음

 

이 response는 INVITE 서버 트랜잭션에 전달되며, 해당 트랜잭션이 재전송을 처리한다.

 

✅ UAS가 INVITE에 포함된 offer를 거부하고자 하는 경우

• 488 (Not Acceptable Here) response를 반환해야 한다. (SHOULD)
• 이 경우 왜 offer가 거부되었는지를 설명하는 Warning 헤더를 포함해야 한다. (SHOULD)

 

(13.3.1.4) The INVITE is Rejected

UAS core가 2xx respone를 생성하면 해당 response는 dialog를 성립시키며, (12.1.1 )과 (8.2.6) 절차를 모두 따라야 한다.

 

INVITE에 대한 2xx resonse는 Allow 헤더와 Supported 헤더를 포함해야 하며 (SHOULD) Accept 헤더는 선택적으로 포함할 수 있다. (MAY)

• 이 헤더들을 포함하면, UAC는 별도로 OPTIONS 등을 이용한 proving 없이 UAS가 지원하는 기능(extension)을 파악할 수 있다.

 

Offer/Answer 모델 처리

✅ INVITE에 offer가 포함되어 있고, UAS가 아직 answer를 보내지 않았다면,

• 2xx response에 반드시 answer를 포함해야 한다. (MUST)

✅ INVITE에 offer가 없고, UAS도 아직 offer를 보내지 않았다면,

• 2xx response에 반드시 offer를 포함해야 한다. (MUST)

 

2xx response가 생성되면, INVITE 서버 트랜잭션에 전달된다.

 

주의사항

• INVITE 서버 트랜잭션은 final response를 전송 계층에 전달한 직후 파괴된다.
• 따라서 ACK가 도착할 때까지 UAS는 주기적으로 해당 2xx response를 전송 계층에 재전송해야 한다.
• 2xx response는 처음에는 T1초 간격으로 전송되며, 재전송될 때마다 최대 T2초가 되기 전까지 간격이 두배씩 증가한다.
  • T1: 초기 재전송 간격 (17절 참조)
  • T2: 최대 재전송 간격
• ACK request가 도착하면, 2xx response의 재전송은 즉시 중단된다.
• 이 재전송 메커니즘은 UDP, TCP 등 어떤 전송 프로토콜을 쓰더라도 반드시 수행해야 함

💬 2xx response는 end-to-end로 전달되며, 중간에 UDP 기반 hop이 존재할 수 있기 때문에, UAS는 재전송을 통해 전송의 신뢰성을 보장해야 한다.