 It was text based. Chapter 4 The concept of registrations to conference address servers was promi- nent in SIPv1. Once a user had registered his or her location, an address server was able to route invitations to the proper user and also provide a certain level of user mobility. If someone were away from his or her normal workstation on business travel, for example, this user could choose to reg- ister his or her temporary workstation and receive invitations to local conferences. Notably, SIPv1 only handled session establishment. Signalling stopped once the user joined the session and mid-conference controls were yet to come. Simple Conference Invitation Protocol: SCIP Also on February 22, 1996, Henning Schulzrinne submitted an Internet draft to the IETF specifying the Simple Conference Invitation Protocol (SCIP). SCIP was also a mechanism for inviting users to point-to-point and multicast sessions. It was based on Hypertext Transfer Protocol (HTTP) and thus utilized Transmission Control Protocol (TCP) as the transport proto- col. Like SIPv1, it was text based. SCIP used e-mail addresses as identifiers for users, aiming to provide a universal identifier for both synchronous and asynchronous communications. SCIP signalling persisted after session establishment to enable parameter changes in ongoing sessions and closing existing sessions. Instead of recycling a mechanism for session description like SDP, it defined a new format for this purpose. Session Initiation Protocol: SIPv2 At the 35th IETF meeting in Los Angeles, Schooler presented SIP and Schulzrinne presented SCIP. During this meeting and through the 36th IETF meeting, the usual colorful level of discussion ensued. Eventually, it was decided to merge the two protocols. The resulting protocol kept SIP as a name, but changed the meaning of the acronym to Session Initiation Protocol and advanced the version to number 2 (Figure 4-2). An Internet draft of SIPv2, authored by Mark Hanley, Schulzrinne, and Schooler, was submitted to the IETF in San Jose during th