On 02-02 17:51, justiceguy(a)pobox.com wrote:
Hello list,
I am new to SER and trying to understand the ramifications and
downsides of SIP Loose Routing versus Strict. I have read RFC3261
and some net documentation, but I'm still having trouble seeing
the big picture.
Someone has decided that handling of Route and Record-Route header
field was underspecified in RFC2543, moreover the way the two header
fields should be processed according to that document was not the best
one.
Therefore, processing of Route and Record-Route header field has been
reworked, it is one of the improvements of RFC3261 over RFC2543.
Proxies and user agents that process Route and Record-Route header
field in conformance with RFC3261 are called loose routers and the
process is called loose routing.
Proxies that implement Route and Record-Route processing according to
RFC2543 are called strict routers and the process is called strict
routing.
Strict router takes the URI from the topomost Route header fields,
puts the URI into the Request-URI and removes the topmost Route header
field before forwarding.
Loose router takes the URI from the topmost Route header field, but
DOES NOT rewrite the Request-URI with it, it just forwards the
message to the URI from the topmost Route header field and deletes the
topmost Route.
In case of strict routing, the Request-URI always contains the URI of
the next hop. In case of loose routing, the Request-URI always
contains the Contact value of the remote end point (user agent).
There are some additional rules which make loose routing backwards
compatible with strict routing to some extent and that is what makes
loose routing so complex and hard to understand, but the basic idea is
described above.
In particular, we are testing a SIP route to an
ITSP, and they have specified to us "no SIP loose routing". I'm
trying to understand, why do providers do this?
Because they do not understand it properly. A proper loose router
(like ser) would detect that the next hop (the proxy or PSTN of the
ITSP) does not support loose routing and would automatically adjust
the header fields so that the strict routing proxy can understand
them.
What is the
downside?
There are no real downsides, execept that loose router -> strict
router forwarding is more complex and error prone.
What are Industry Best Practices?
Use loose routing everywhere, devices that do not support it should be
upgraded to support it (or tossed away if that is not possible).
We have some downstream customers that might be
connecting
Asterisk IAX to us, and then we will be routing these calls via
SIP to the ITSP provider. It seems to me that there might be
ramifications for loose versus strict routing in how we process
these calls.
Normally you would not care, SER should do all that automagically.
It can detect strict routers and it would enter the backwards
compatibility mode automatically.
Can anyone with SIP routing experience explain best
practices or
Advantages/Disadvantages, or point me to a link?
I found a document that explains the 'problem' with Strict
routing:
“Strict” routing (Route/Record-Route as defined in bis-05 and
before) was too strict. Service logic could not affect routing of
the initial request.
That sentence is wrong. There is nothing too strict about strict routing,
it is just another way of achieving the same -- getting a request through a
set of proxies.
Neither strict routing nor loose routing is used to route the initial
request (the one that establishes a dialog). Strict/loose routing is
used for mid-dialog requests only (ACK, BYE, NOTIFY, ..).
* Strict routing conflates the request target with the
next hop
destination.
Yes, that is correct.
* Strict route processing throws away the information
in the
received Request-URI.
Yes. Loose routing throws away the information in the received
topmost Route header field.
* Behavior of UAs with default-outbound-proxies
problematic.
Yes. That is one of the cases where loose routing is not backwards
compatible with strict routers -- using of pre-loaded route set to
specify the outbound proxy.
* Brittle system failure if any element misroutes.
No difference between strict and loose routing. What adds the
brittleness is underspecification strict routing in RFC2543 and backwards
compatiblity introduced in RFC3261.
Jan.