Via, Record-Route, Route (Strict Routing, Loose Routing)의 차이

Via 필드는 UAC가 전송한 SIP Request 메세지의 경로를 기록하고 SIP 메세지를 전송한 역방향으로 SIP Response를 수신받기 위해 사용됩니다.
Route 헤더는 UAC가 SIP Request를 보낼 Proxy 주소를 알고 있을때 사용되는 헤더로, 소스라우팅과 비슷한 개념으로 동작합니다.
Record-Route 헤더는 위의 Router 헤더의 정보를 채우기 위해 SIP Proxy의 주소를 기록할때 사용됩니다. 동작은 Via헤더와 비슷하지만. 두가지의 쓰임새가 전혀 다름니다.

Via 는 E2E SIP 라우팅 정보를 기록하지만(UAC, UAS모두 포함)
Record-Route는 SIP Proxy 주소의 라우팅 정보만(UAC, UAS 미 포함)을 기록합니다.

Record-route : Proxy 에서 dialog 내의 request 를 받고자 할 때 사용
Route : record-route header 의 list로 만들어 지며 request 가 거쳐 가야할 Proxy의 경로..

routing
route set 이 존재할 경우 Proxy를 거칠 때마다 URI 를 Record-route 헤더에 기록
route set 은 dialog 성립시 결정 (or 초기 기본값으로 결정)


[code]
대충 정리하자면 via는 request 한놈에게 response 하면 되고
record-route 는 proxy 에 dialog 가 있으면 write 해서 response 하는 것이고
route 는 record-route 로 생성된 list 를 (ua -> ub 로 생성시) ub -> ua로
request 할때 proxy 에 request 경로로 사용 한다.


16.12.1.1 Basic SIP Trapezoid

u1 -> p1 -> p2 -> u2 의 경우

new request 일 때
via

u1 이 send 시
INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com

P1는 outboundproxy 이다. p1 는 domain.com 에 책임을 지지 않는다.

p1 에서 p2 로 갈때 record-route 가 추가되고

INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route:

p2 가 u2 로 갈때 마찬가지로 record-route 가 추가된다.

INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route:
Record-Route:

u2 는 200 ok 를 return 한다.

SIP/2.0 200 OK
Contact: sip:callee@u2.domain.com
Record-Route:
Record-Route:

이 때 BYE request 를 u1 이 u2 에게 한다면은

BYE sip:callee@u2.domain.com SIP/2.0
Route: ,

와 같이 진행 하고 P1 이 P2 를 향할 땐 아래와 같이 메시지를 날린다.

BYE sip:callee@u2.domain.com SIP/2.0
Route:

그리고 최종적으로

BYE sip:callee@u2.domain.com SIP/2.0

가 된다.

U2 가 U1 에게 한다면은 당근

BYE sip:caller@u1.example.com SIP/2.0
Route: ,

가 되지 않을까?

// -----------------------------------------------------

16.12.1.2 Traversing a Strict-Routing Proxy

U1->P1->P2->P3->P4->U2 상태 일때

U2 는 최종적으로 아래와 같이 INVITE를 받는다.
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route:
Record-Route:
Record-Route:
Record-Route:

이후 200 OK 를 보내고 U2 는 P4 에게 BYE request 를 하는데
다음과 같다.

BYE sip:caller@u1.example.com SIP/2.0
Route:
Route:
Route:
Route:

p4 는 p3 에게 다음과 같이 BYE 를 Request 한다.

BYE sip:p3.middle.com SIP/2.0
Route:
Route:
Route:

p3 가 strict router 면 p2 에 다음처럼 포워딩 한다.

BYE sip:p2.example.com;lr SIP/2.0
Route:
Route:

p2 역시 p1 에게 위와 같은 방식으로 전달하고

p1 는 u1 에게 다음과 같이 전달한다.

BYE sip:caller@u1.example.com SIP/2.0


// --------------------------------------------------------

Rewriting Record-Route Header Field Values

U1->P1->U2

다음과 같은 상황일 때 U1 은 다음 처럼 SEND 한다.

INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
Contact:

P1 은 location 서비스 이므로 다음과 같이 처리 한다.

INVITE sip:callee@rightprivatespace.com SIP/2.0
Contact:
Record-Route:

U2 가 받았으면 200 OK 를 P1 에게 리턴한다.

SIP/2.0 200 OK
Contact:
Record-Route:

U1 이 P1 에게 BYE 를 요청한다면

BYE sip:callee@u2.rightprivatespace.com SIP/2.0
Route:

P1 이 U2 에게 포워딩 해준다.

BYE sip:callee@u2.rightprivatespace.com SIP/2.0

// ------------------------------------------------------------------

U1 -> P1 -> U2 일 때 VIA는 U1, P1 에서 담에 U2 가 response 할 때 이용된다.

// ------------------------------------------------------------------

U1 -> P1 -> P2 -> P3 -> U2 일 때

VIA 는 U1, P1, P2, P3 에서 담고
Record-route 는 P1, P2, P3 에서 담는다.

U2 에서 U1 으로 Response 시 VIA 를 따르고

U2 에서 U1 으로 Request 시
VIA는 U2, P3, P2, P1 에서 담고
Record-route 로 Route 를 참조해
P3 -> P2 -> P1 -> U1 으로 향한다.
[/code]

이하 RFC 3261

// ---------------------------------------------------------------------------------------

20.42 Via

The Via header field indicates the path taken by the request so far
and indicates the path that should be followed in routing responses.
The branch ID parameter in the Via header field values serves as a
transaction identifier, and is used by proxies to detect loops.

A Via header field value contains the transport protocol used to send
the message, the client's host name or network address, and possibly
the port number at which it wishes to receive responses. A Via
header field value can also contain parameters such as "maddr",
"ttl", "received", and "branch", whose meaning and use are described

[code]via는 도메인 이름이나 ip 주소, 포트 번호등을 넣어서 구성할 수 있다. via 헤더 필드값은 다음에 4가지의 파라메터를 실을 수 있는데
"maddr", "ttl", "received", and "branch" 가 있다. 전송 프로토콜은 "UDP", "TCP", "TLS", and "SCTP" 다음에 프로토콜을 구성할 수 있다. branch 의 경우 첫 파라메터가 매직 쿠키 "z9hG4bK" 를 가져야 되며 이것은 8.1.1.7 에 묘사되어 있다. [/code]

in other sections. For implementations compliant to this
specification, the value of the branch parameter MUST start with the
magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.

Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
"TLS" means TLS over TCP. When a request is sent to a SIPS URI, the
protocol still indicates "SIP", and the transport protocol is TLS.

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
;branch=z9hG4bK77asjd

The compact form of the Via header field is v.

In this example, the message originated from a multi-homed host with
two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong
as to which network interface would be used. Erlang.bell-
telephone.com noticed the mismatch and added a parameter to the
previous hop's Via header field value, containing the address that
the packet actually came from.

The host or network address and port number are not required to
follow the SIP URI syntax. Specifically, LWS on either side of the
":" or "/" is allowed, as shown here:

Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1

Even though this specification mandates that the branch parameter be
present in all requests, the BNF for the header field indicates that
it is optional. This allows interoperation with RFC 2543 elements,
which did not have to insert the branch parameter.

Two Via header fields are equal if their sent-protocol and sent-by
fields are equal, both have the same set of parameters, and the
values of all parameters are equal.


----------------------------------------------------------------------

20.34 Route

The Route header field is used to force routing for a request through
the listed set of proxies. Examples of the use of the Route header
field are in Section 16.12.1.

Example:

Route: ,


----------------------------------------------------------------------


20.30 Record-Route

The Record-Route header field is inserted by proxies in a request to
force future requests in the dialog to be routed through the proxy.

Examples of its use with the Route header field are described in
Sections 16.12.1.

Example:

Record-Route: ,


----------------------------------------------------------------------

16.12.1.1 Basic SIP Trapezoid

This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with
both proxies record-routing. Here is the flow.


U1 sends:

INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com

to P1. P1 is an outbound proxy. P1 is not responsible for
domain.com, so it looks it up in DNS and sends it there. It also
adds a Record-Route header field value:

INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route:

P2 gets this. It is responsible for domain.com so it runs a location
service and rewrites the Request-URI. It also adds a Record-Route
header field value. There is no Route header field, so it resolves
the new Request-URI to determine where to send the request:

INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route:
Record-Route:

The callee at u2.domain.com gets this and responds with a 200 OK:

SIP/2.0 200 OK
Contact: sip:callee@u2.domain.com
Record-Route:
Record-Route:

The callee at u2 also sets its dialog state's remote target URI to
sip:caller@u1.example.com and its route set to:

(,)

This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its
dialog state's remote target URI to sip:callee@u2.domain.com and its
route set to:

(,)

Since all the route set elements contain the lr parameter, U1
constructs the following BYE request:

BYE sip:callee@u2.domain.com SIP/2.0
Route: ,


As any other element (including proxies) would do, it resolves the
URI in the topmost Route header field value using DNS to determine
where to send the request. This goes to P1. P1 notices that it is
not responsible for the resource indicated in the Request-URI so it
doesn't change it. It does see that it is the first value in the
Route header field, so it removes that value, and forwards the
request to P2:

BYE sip:callee@u2.domain.com SIP/2.0
Route:

P2 also notices it is not responsible for the resource indicated by
the Request-URI (it is responsible for domain.com, not
u2.domain.com), so it doesn't change it. It does see itself in the
first Route header field value, so it removes it and forwards the
following to u2.domain.com based on a DNS lookup against the
Request-URI:

BYE sip:callee@u2.domain.com SIP/2.0

16.12.1.2 Traversing a Strict-Routing Proxy

In this scenario, a dialog is established across four proxies, each
of which adds Record-Route header field values. The third proxy
implements the strict-routing procedures specified in RFC 2543 and
many works in progress.

U1->P1->P2->P3->P4->U2

The INVITE arriving at U2 contains:

INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route:
Record-Route:
Record-Route:
Record-Route:

Which U2 responds to with a 200 OK. Later, U2 sends the following
BYE request to P4 based on the first Route header field value.

BYE sip:caller@u1.example.com SIP/2.0
Route:
Route:
Route:
Route:


P4 is not responsible for the resource indicated in the Request-URI
so it will leave it alone. It notices that it is the element in the
first Route header field value so it removes it. It then prepares to
send the request based on the now first Route header field value of
sip:p3.middle.com, but it notices that this URI does not contain the
lr parameter, so before sending, it reformats the request to be:

BYE sip:p3.middle.com SIP/2.0
Route:
Route:
Route:

P3 is a strict router, so it forwards the following to P2:

BYE sip:p2.example.com;lr SIP/2.0
Route:
Route:

P2 sees the request-URI is a value it placed into a Record-Route
header field, so before further processing, it rewrites the request
to be:

BYE sip:caller@u1.example.com SIP/2.0
Route:

P2 is not responsible for u1.example.com, so it sends the request to
P1 based on the resolution of the Route header field value.

P1 notices itself in the topmost Route header field value, so it
removes it, resulting in:

BYE sip:caller@u1.example.com SIP/2.0

Since P1 is not responsible for u1.example.com and there is no Route
header field, P1 will forward the request to u1.example.com based on
the Request-URI.

16.12.1.3 Rewriting Record-Route Header Field Values

In this scenario, U1 and U2 are in different private namespaces and
they enter a dialog through a proxy P1, which acts as a gateway
between the namespaces.

U1->P1->U2


U1 sends:

INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
Contact:

P1 uses its location service and sends the following to U2:

INVITE sip:callee@rightprivatespace.com SIP/2.0
Contact:
Record-Route:

U2 sends this 200 (OK) back to P1:

SIP/2.0 200 OK
Contact:
Record-Route:

P1 rewrites its Record-Route header parameter to provide a value that
U1 will find useful, and sends the following to U1:

SIP/2.0 200 OK
Contact:
Record-Route:

Later, U1 sends the following BYE request to P1:

BYE sip:callee@u2.rightprivatespace.com SIP/2.0
Route:

which P1 forwards to U2 as:

BYE sip:callee@u2.rightprivatespace.com SIP/2.0