re-INVITE를 통하여 addresses, ports 변경과 media stream 추가, 삭제등이 가능 함

Caller와 Callee 모두 수정 가능

media failure는 local policy에 따르지만 자동으로 re-INVITE나 BYE를 생성하는것은 추천하지 않음 (NOT RECOMMENDED)

14.1 UAC Behavior^#

INVITE에서 사용되었던 offer-answer model이 re-INVITE에도 동일하게 적용, full description을 적어서 INVITE를 생성해야 함

session descrption에 version을 보고 offerer가 session descrption이 변화 되었음을 알아야 함

re-INVITE의 To, From, Call-ID, CSeq, Request-URI는 dialog안에서의 request의 처리와 동일하게 처리

Alert-Info header나 body의 Content-Disposition을 "alert"로 하지 않을 수도 있음

re-INVITE는 forking 되지 않음

다른 INVITE transaction이 진행중이라면 새로운 INVITE transaction을 생성하면 안됨

INVITE client transaction이 진행중이라면 TU는 transaction이 completed나 terminated 될 때까지 기다려야 함
INVITE server transaction이 진행중이라면 TU는 transaction이 confirmed이나 terminated 상태로 천이 될때까지 기다려야 함

regular transaction이 진행중이라면 INVITE transaction을 생성 할 수 있고 그 반대도 성립 도리 수 있음

re-INVITE에 대하여 non-2xx final response를 받았다면 session은 변경되지 않음

481 (Call/Transaction Does Not Exist), 408 (Request Timeout)나 아무 response를 받지 않았다면 dialog를 종료함
491 response를 받았을 경우T의 값을 가지는 타이머를 시작함
1. UAC가 Call-ID의 소유자라면 2.1에서 4초에서 10ms 단위로 랜덤값을 정함
2. UAC가 Call-ID의 소유자가 아니라면 0에서 10ms 단위를 이용 2초 사이의 랜덤값을 정함
- 타이머가 종료되면 re-INVITE를 다시 시도함

ACK의 전송은 Section 13.2.1의 과정과 동일함

14.2 UAS Behavior^#

Section 13.3.1은 initial INVITE의 re-INVITE와 existing dialog의 INVITE의 구별과정을 설명하고 있음

첫번째 INVITE에 대하여 final response를 보내지 않았는데 두번째 INVITE가 올 경우, 두번째 INVITE에 대하여 500 (Server Internal Error) response를 Retry-After header field와 함께 보냄

UAS에 같은 dialog에서 INVITE를 보낸 후 INVITE를 수신 하였다면 그 INVITE에 대하여 491 (Request Pending) response를 전달 함

existing dialog에 re-INVITE를 받았다면 session description의 버전이나 session description의 contents를 확인하여야 함

새로운 session discription이 허용되지 않는다면 488 (Not Acceptable Here) response 을 이용하여 거절

2xx response 생성후 ACK를 받지 않았다면 BYE를 통하여 dialog를 종료

re- INVITE에 대하여 180 (Ringing) responses를 생성 할 수 없음

새로운 콜의 생성이나 존재하는 session을 업데이트의 이유로 2xx response에 UAS를 offer를 제공 할 수 있음