Network transport를 이용하여 transport layer가 실제로 request와 response를 전송
address, ort, transport protocol의 tuple로 인덱스한 connection들을 관리
client transport와 server transport로 구성
connection은 공유할 수 있음
18.1 Clients#
18.1.1 Sending Requests#
MTU를 알 경우는 MTU-200 보다 크거나, MTU를 모를 경우 1300바이트 이상이라면 TCP를 이용하여 전달
멀티캐스트로 보낼 경우는 maddr 파라매터 추가하고 ttl을 1로 셋팅
sent-by 값을 추가하여야 함
같은 connection 또는 다른 connection으로 response가 올 수 있으므로 준비하여야 함
멀티캐스트의 경우는 멀티캐스트로 response가 올 수 있으므로 준비하여야 함
18.1.2 Receiving Responses#
최상위 Via의 sent-by가 clinet transport를 나타내는지 확인
해당 client transacton을 찾음, 찾으면 해당 transaction으로 아니면 Core로 보냄
18.2 Servers#
18.2.1 Receiving Requests#
자신이 알려둔 주소에 대해서는 모든 connection을 열어야 함
UDP로 열어 놓은 connetion은 TCP로 열어야 함
sent-by 파라매터를 체크한후 received 파라매터 추가
18.2.2 Sending Responses#
top Via header field를 이용하여 response를 보낼 곳을 결정
- reliable transport protocol은 존재하는 connection을 이용, 더이상 존재하지 않으면 connection을 생성
- maddr 파라매터가 존재한다면 sent by의 포트 없다면 5060, ttl 파라매터 없으면 1로 셋팅한후 해당 주소로 보냄
- unreliable unicast transport의 경우, received 파라매터가 있다면 해당 주소와 sent-by의 포트 없으면 5060으로 보냄
- receiver-tag가 없으면 sent-by의 주소를 이용 [4] Section 5 절차를 따라 처리
18.3 Framing#
mesage-oriented transports의 경우 Content-Length header field의 값과 비교 하여 추가로 온 부분은 삭제하고 모자라면 에러를 발생
stream-oriented의 경우는 Content-Length는 바디의 사이즈를 나타냄
18.4 Error Handling#
request, response에 독릭적으로 에러 처리
unreliable transport인 경우 ICMP error 타입에 따라 다르게 처리
reliable transport인 경우 transport user에게 알림
'Protocol > SIP' 카테고리의 다른 글
| 22. Usage of HTTP Authentication (0) | 2013.09.25 |
|---|---|
| 19. Common Message Components (0) | 2013.09.25 |
| 17. Transactions (0) | 2013.09.25 |
| 16. Proxy Behavior (0) | 2013.09.25 |
| 15. Terminating a Session (0) | 2013.09.25 |