Strict Vs Loose Routing

http://www.ietf.org/rfc/rfc3261.txt

Strict routing (Strict Routing):
The reason can be understood as a more "rigid" mechanism, such a routing mechanism as defined in the SIP protocol predecessor RFC 2534, the mechanism is very simple.
Requirements of the received message Request-URI must own URI, then it will first Route header field "bombs", and the URI as a new request-rui, then the message is routed to the URI .

Loose routing (the Louse Routing, lr):
The routing mechanism is more flexible, but also the soul of the SIP routing mechanism defined in the SIP fundamental ceremony RFC 3261.

RFC3261 (Almost).ppt

16.12 Summary of Proxy Route Processing

In the absence of local policy to the contrary, the processing a
proxy performs on a request containing a Route header field can be
summarized in the following steps.

1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI.

2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached).

3. The proxy will forward the request to the resource indicated
by the URI in the topmost Route header field value or in the
Request-URI if no Route header field is present. The proxy
determines the address, port and transport to use when
forwarding the request by applying the procedures in [4] to
that URI.

If no strict-routing elements are encountered on the path of the
request, the Request-URI will always indicate the target of the
request.

16.12.1 Examples

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.

Rosenberg, et. al. Standards Track [Page 118]

RFC 3261 SIP: Session Initiation Protocol June 2002

U1 sends:

INVITE sip:moc.niamod|eellac#moc.niamod|eellac SIP/2.0
Contact: sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac

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:moc.niamod|eellac#moc.niamod|eellac SIP/2.0
Contact: sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac
Record-Route: <sip:p1.example.com;lr>

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:moc.niamod.2u|eellac#moc.niamod.2u|eellac SIP/2.0
Contact: sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>

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

SIP/2.0 200 OK
Contact: sip:moc.niamod.2u|eellac#moc.niamod.2u|eellac
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>

The callee at u2 also sets its dialog state's remote target URI to
sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac and its route set to:

(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its
dialog state's remote target URI to sip:moc.niamod.2u|eellac#moc.niamod.2u|eellac and its
route set to:

(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

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

BYE sip:moc.niamod.2u|eellac#moc.niamod.2u|eellac SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

Rosenberg, et. al. Standards Track [Page 119]

RFC 3261 SIP: Session Initiation Protocol June 2002

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:moc.niamod.2u|eellac#moc.niamod.2u|eellac SIP/2.0
Route: <sip:p2.domain.com;lr>

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:moc.niamod.2u|eellac#moc.niamod.2u|eellac 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:moc.niamod.2u|eellac#moc.niamod.2u|eellac SIP/2.0
Contact: sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>

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:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>

Rosenberg, et. al. Standards Track [Page 120]

RFC 3261 SIP: Session Initiation Protocol June 2002

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: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac>

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

BYE sip:p2.example.com;lr SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac>

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:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac SIP/2.0
Route: <sip:p1.example.com;lr>

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:moc.elpmaxe.1u|rellac#moc.elpmaxe.1u|rellac 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.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License