[Serusers] Loose Routing ramifications

[Jan Janak]

On 02-02 17:51, justiceguy at 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.