Response Processing

Response matching 시도
Matching되지 않으면 : stateless proxy 처럼 동작
Matching 되는 경우 : client transaction에서 proxy layer로 전달
Proxy layer에서 하는 일
1. Find context
- response context 검색

2. Update timer C for provisional responses
- Timer C reset

3. Remove the topmost Via
- Via field의 최상단의 값 삭제
- CANCEL의 경우 없음

4. Add the response to the response context
- Server transaction 에 의해 response가 만들어 질때 까지 response context에 보관
- server transaction으로 부터 best final response가 return되면 이용

5. Check response for forwarding
- 2xx와 provisional response(100 Trying 제외)는 즉시 forwarding
- 100 Trying response 전달하지 않음
- 6xx response : pending client transaction 삭제
- 즉시 보내야하는 response는 7 번째 step으로 이동(Aggregate
Aggregate authorization header field values step)

6. Choosing the best response
- Final response을 response context의 server transaction에게 보냄
- response context의 모든 client transaction 삭제
- proxy는 response context에 저장되어졌거나 받은 것 중 “best” final response을 선택

7. Aggregate authorization header field values if necessary
- response가 401(Unauthorized) or 407(Proxy Authentication Required) 경우
- 전달하기 전에 response에 WWW-Authenticate와 proxy-Authenticate header field 값 포함

8. Record-Route
- Record-Route field 수정가능
- 예) TLS에 의해 request수신하였으나 non-TLS와 연결된 서버에 이를 보낸경우 response을 다시 SIPS URI로 수정하여 보낸다.

9. Forward the response
- Proxy는 server transaction에게 response 전달
- server transaction은 Via의 최상단 주소로 response 전달

10. Generate CANCEL
- CANCEL 생성 : Response가 2xx 일때
- Pending client transaction 삭제
- 6xx response일 경우도 동일