[RFC 3261] CHAPTER 14. Modifying an Existing Session

 

CHAPTER 14. Modifying an Existing Session

 

12절에서는 기존 dialog를 target refresh 요청을 통해 수정하는 방법을 설명했다. 해당 14절에서는 주소/포트 변경, 미디어 스트림 추가/삭제 등 세션을 수정하는 방법을 설명한다.

 

성공적인 INVITE request는 두 UA간 dialog와 offer/answer 모델을 통해 세션을 동시에 설정한다.

 

세션 수정은 기존 세션을 설정했던 동일한 dialog 내에서 새로운 INVITE request를 보내는 방식으로 수행된다.

• 기존 dialog 내에서 보내는 INVITE request를 re-INVITE라고 한다.
• 하나의 re-INVITE가 dialog와 세션 파라미터를 동시에 수정할 수 있다는 점을 유의해야 한다.

 

caller(발신자)나 callee(착신자) 모두 기존 세션을 수정할 수 있다.

• 미디어 실패를 감지했을 때, UA가 어떻게 동작할지는 로컬 정책에 따라 결정된다.
• 그러나 자동으로 re-INVITE나 BYE를 생성하는 것은 권장되지 않는다. (NOT RECOMMENDED)
  → 네트워크 트래픽 폭주를 초래할 수 있다.
• 그럼에도 불구하고 자동으로 메세지를 전송해야 한다면, 일정한 랜덤 시간 간격 후에 전송해야 한다. (SHOULD)

※ (수동 예외) 사용자가 미디어 실패로 인해 직접 끊은 경우에는, UA는 평소처럼 BYE를 전송하면 된다.

 

 

(14.1) UAC Behavior

 

Initial INVITE에서의 offer/answer 모델 (13.2.1절)은 re-INVITE에서도 동일하게 적용된다.

• 예: 미디어 스트림을 추가하고 싶을 경우, 해당 스트림을 포함한 새로운 offer를 생성하여 peer에게 re-INVITE를 전송.
• ⚠️ 변경 사항만 보내는 것이 아니라, 전체 SDP을 보내야 한다.
• 이 방식은 중간 노드나 프록시에서 stateless하게 세션 처리를 할 수 있도록 하며, 장애 발생 시 복구 기능을 지원한다.
• UAC가 SDP 없이 re-INVITE를 보내면, 첫 번째 final 2xx response가 offer를 포함하게 된다. (MAY)
  → delayed offer 방식: UAS가 먼저 offer 전송

 

• SDP 형식이 버전 번호를 지원한다면, offer는 버전 번호가 변경되었음을 표시해야 한다. (SHOULD)
• re-INVITE의 To, From, Call-ID, CSeq, Request-URI 는 (12절) dialog 내 request 규칙에 따라 설정된다.
• 일반적으로 re-INVITE에는 Alter-Info 헤더나 “alter” 값을 지닌 Content-Disposition 헤더를 갖는 body를 포함시키지 않는다. (MAY)

→ UAS는 re-INVITE 수신 시 사용자에게 알람을 울리지 않는 경우가 대부분이기 때문이다.

 

Initial INVITE는 fork 될 수 있지만, re-INVITE는 절대 fork 되지 않으며, final response도 항상 하나만 생성된다.

→ Request-URI가 특정 AOR이 아닌, dialog가 형성된 특정 UA 인스턴스를 식별하기 때문이다.
→ re-INVITE는 기존 dialog의 상대방 하나에게만 도달. 단일 경로, 단일 응답

 

UAC는 dialog 내에서 INVITE 트랜잭션이 진행 중일 때, 새로운 트랜잭션을 시작하면 안된다. (MUST NOT)

1. UAC가 INVITE 클라이언트 트랜잭션을 이미 진행 중인 경우,
   • 새로운 re-INVITE는 해당 트랜잭션이 completed 또는 terminated 상태일 때만 전송 가능하다. (MUST)
2. 상대방의 INVITE 서버 트랜잭션이 진행 중인 경우,
   • 새로운 re-INVITE는 상대방 트랜잭션이 confirmed 또는 terminated 상태일 때만 전송 가능 (MUST)

 

INVITE 트랜잭션이 진행 중인 상황에서도, 일반 트랜잭션(예: OPTIONS, BYE)은 시작할 수 있다. (MAY) 반대로 일반 트랜잭션이 진행 중일 때도 INVITE는 시작할 수 있다. (MAY)

 

 

만약 re-INVITE에 대해 non-2xx final response를 받았다면, 세션 파라미터는 변경되지 않으며, re-INVITE를 시도하지 않았던 것처럼 유지되어야 한다. (MUST)

• 만약 non-2xx final response가 다음과 같다면, UAC는 dialog를 종료해야 한다. (12.2.1.2 참고)
  • 481 (Call/Transaction Does Not Exist) response
  • 408 (Request Timeout) response
  • response가 아예 없음

 

UAC가 re-INVITE에 대해 491(Request Pending) response를 받으면, 타이머 T를 시작해야하며, T의 값은 다음 규칙에 따라 선택한다. (SHOULD)
→ race condition이 발생한 상황: 두 UAC 중 누가 먼저 재시도 할지를 정하기 위한 메커니즘

1. 만약 UAC가 해당 dialog ID의 Call-ID를 직접 생성한 주체라면, T는 2.1초 ~ 4초 사이의 임의의 값으로 설정되어야 하며, 단위는 10ms이다.
2. 반대로 UAC가 주체가 아니라면, T는 0 ~ 2초 사이의 임의의 값으로 설정되어야 하며, 단위는 10ms이다.

 

타이머가 만료되었고, UAC는 세션 변경을 여전히 원한다면, re-INVITE를 다시 시도해야 한다. (SHOULD)

• 예를 들어, 이미 BYE로 세션이 종료되었다면, re-INVITE는 다시 시도되지 않는다.

 

re-INVITE를 전송하는 규칙과 re-INVITE에 대한 2xx-response의 ACK를 생성하는 규칙은 Initial INVITE와 동일하다. (13.2.1절 참고)

---

(14.2) UAS Behavior

 

UAS가 기존 dialog에서 더 낮은 CSeq 값을 가진 INVITE에 대해 아직 final response를 보내기 전인데, 새로운 INVITE를 수신한 경우, (MUST)

• 500 (Server Internal Error) response 전송
• Retry-After 헤더 포함 (값: 0~10초 사이 임의)

→ 동일 dialog에서 순차적인 INVITE 순서 보장 필요

→ 아직 처리 중인 이전 INVITE가 있는데 새로운 INVITE가 오면, 내부 충돌로 보고 500 반환

 

동일 dialog에서 UAS가 자신이 보낸 INVITE를 아직 처리 중인데 새 INVITE를 수신한 경우, 반드시 491(Request Pending) response를 보내야 한다. (MUST)

 

동일 dialog에서 UA가 re-INVITE를 수신한 경우, (MUST)

• SDP의 버전 식별자를 확인
• 버전 정보가 없다면, 내용 자체를 비교해 변경 여부 판단

SDP가 변경된 경우, UAS는 세션 파라미터를 조정해야 하며, 필요시 사용자의 동의를 구할 수도 있다. (MUST)

SDP 버전 관리는, 새로운 참가자의 기능 수용, 미디어 추가/삭제, 유니캐스트 → 멀티캐스트 전환 등을 위해 사용될 수 있다.

 

UAS가 session description을 수용할 수 없는 경우,

• 해당 re-INVITE에 대해 488 (Not Acceptable Here) response를 반환하여 거절할 수 있다.
• 이 response에는 Warning 헤더가 포함되어야 한다. (SHOULD)

UAS가 2xx response를 보낸 후 ACK를 수신하지 못한 경우,

• BYE request를 생성하여 dialog 종료해야 한다. (MUST)

 

UAS는 re-INVITE에 대해 180 (Ringing) response를 생략할 수 있다. (MAY)
→ UAC가 해당 정보를 사용자에게 표시하지 않기 때문

• 같은 이유로 UAS는 re-INVITE에 대한 response에서 Alter-Info 헤더나 “alert” 값으로 설정된 Content-Disposition 헤더를 사용하지 않을 수 있다. (MAY)

 

UAS가 2xx response 내에서 offer를 제공해야 할 경우, → delayed offer

• 마치 새로운 call을 시작하는 것처럼 offer를 구성해야 한다. (SHOULD)
• 단, 기존 세션과의 일관성은 유지해야 함 (13절 참고)
• UA가 지원하는 가능한 많은 미디어 포맷과 타입 포함해야 한다.(SHOULD)
• 이전 session description과 겹치는 내용을 유지해야 한다. (MUST)
  • 미디어 포맷, 전송 방식, peer의 지원이 필요한 다른 기타 파라미터 포함
  • 이는 peer가 session description을 거부하는 상황을 방지하기 위한 것이다.
• 만약 UAC가 해당 SDP를 수용할 수 없다면,
  • 유효한 SDP가 포함된 answer을 생성한 후, BYE를 전송하여 세션 종료해야 한다. (SHOULD)