IP trunk offerings, without requiring the rest of the network to be upgraded, or to be SIP-capable. The migration of the entire enterprise network to SIP can therefore be done in a timeline suitable to your business needs, while at the same time you can make SIP trunk services and benefits available to your user community. Industry efforts such as the SIPconnect forum (refer to http://www.sipforum.org/sipconnect for more information) strive to ease the collective migration to SIP, but the progress across the industry is slow, and business benefits can be accrued immediately if an interconnect device is used to resolve the interoperability problems. Chapter 8: Interworking 145 SIP Normalization The previous sections covered many reasons why it might be necessary to manipulate SIP messaging as it flows through your network or to a SIP trunk provider's network. In summary, SIP incompatibilities arise due to: A device rejecting an unknown header (or value or parameter) instead of ignoring it A device sending incorrect data in a SIP message A device not implementing (or incorrectly implementing) protocol procedures A device expecting an optional header value or parameter that can be implemented in multiple ways A device sending a value or parameter that must be changed or suppressed before it leaves or enters the enterprise to comply with policies or the SP UNI Variations in the SIP standards of how to achieve certain functions Privacy settings that must often be set for calls that flow off-net but that are not nec- essary for internal-only calls An application requiring an optional header for proper operation, and other applica- tions or endpoints that do not implement that optional header These incompatibilities often can be resolved with SIP Normalization: a blanket term describing the manipulation or customization of SIP messages by adding, modifying, or deleting certain elements within the messages. This manipulation can affect the content of the SIP headers or SDP headers. Figure 8-2 shows two examples of SIP No