On 02-02 17:51, justiceguy(a)pobox.com wrote: 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. 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. There are no real downsides, execept that loose router -> strict router forwarding is more complex and error prone. Use loose routing everywhere, devices that do not support it should be upgraded to support it (or tossed away if that is not possible). 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. 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, ..). Yes, that is correct. Yes. Loose routing throws away the information in the received topmost Route header field. 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. No difference between strict and loose routing. What adds the brittleness is underspecification strict routing in RFC2543 and backwards compatiblity introduced in RFC3261. Jan.