an be used during a session. Extensions supported: Extensions supported: Extensions supported by both systems established at a particular moment. However, at any other moment, they might decide to use a subset of all the extensions they support. SIP main- tains a clear distinction at all times between the extensions that are under- stood by both parties and those that will be used in a particular session. How It's Done The process of negotiating the session's extensions is conducted using two headers: Require and Supported [draft-ietf-sip-serverfeatures]. A client lists all of the extensions it needs to establish a session in the Require header and all of the extensions it supports in the Supported header. The server decides which extensions will be used in the session based on these two headers. Chapter 6 At the other end, the server lists the extensions that will be used in the Require header and the extensions it understands in the Supported header. This way, the server reciprocates the client's information about which extensions it supports. In Figure 6-2, Bob's UA supports extensions fool, foo2, foo3, and foo4. Bob wants to use extension fool in the session, SO he adds it to the Require header of his INVITE. Laura wants to use extension foo2 as well. She knows that Bob's UA supports it because it appears in the Supported header of the INVITE. Therefore, she adds foo2 to the Require header. Besides that, she tells Bob's UA that her UA also supports foo4 and foo5. Now the Require header in the 200 OK from Laura contains the extensions that will actually be used through the session. The information contained in the Supported header might prove useful later if Bob decides mid-session to use the extension foo4 as well; he is forearmed with the knowledge that it's available and can make a user's decision to expand his session capabilities. The extensions foo3 and foo5 will not be used in the session because they are only understood by one of the end systems. Design Principles for SIP Extensions Effective design fo