ies but may also visit other proxies as needed. Also, a preloaded Route header may be constructed at the start of a dialog without first receiving a Record-Route header in dialog setup. This permits much more flexible routing for services and mobile applications. They can also be used to provide midcall services and home proxy services as discussed in Chapter 9. In addition, the mechanism used is much cleaner and understandable than the old "strict" routing, and it is also backwards compatible, even in a mixed network of strict and loose routing proxies. A major improvement in RFC 3261 comes in the security area. Besides the deprecation of HTTP Basic authentication and PGP and the addition of S/MIME for bodies, the specification also introduces the secure SIP (sips) URI scheme, which requires the use of end-to-end TLS transport (with the exception of the last hop, which may use some other encryption mechanism). This allows a UA to know that the SIP message path does not traverse any unen- crypted links end-to-end through the presence of intermediary proxies. Other changes include a new requirement that Contact URIs be glob- ally routable (which is useful in certain call control scenarios). SIP now also includes full support for IPv6 addresses. The use of hostnames instead of literal addresses is now recommended in Via and Contact URIs. The new specifi- cation renames the "call leg" as a dialog. The definition of a dialog was also changed SO that it includes the To and From tags but not URIs. This will allow future versions of SIP to permit To and From URIs to be changed within a dia- log for clarity. (For example, if A calls B but the call is forwarded to C, when C answers, the 200 OK could contain the URI of C instead of B in the To header field, alerting A that C not B has picked up the call.) The new specification also formally defines an "early" dialog, which is cre- ated when a response to an INVITE (or SUSCRIBE) is received which con- tains a tag. In the case of forking, multiple independent early dialogs m