SIP:

SIP History To begin with, the IETF published SIP version 1.0 in 1997 and SIP version 2.0 in 1998 as Internet Draft (ID). IDs are working documents of the IETF and involved work groups.

In March 1999, SIP Version 2.0 was declared to be an Internet Standard named RFC 2543. In June 2002 the updated version of this first standard was published as RFC 3261. Similar to HTTP, the Hypertext Transfer Protocol (RFC2616), SIP bases its signaling in a request/response transaction model From SMTP, the Simple Mail Transfer Protocol (RFC2821), SIP borrows the header format with the fields 'From', 'To' and 'Content-Type'. Similarly, SIP adapts the Text-Encoding scheme Multi-Internet Mail-Extensions (MIME). The protocol is therefore open to additional services that could be set up in the future

SIP can be used for both transport based on UDP, as well as on TCP, UDP being the more common variant. areas of application: - Presence Buddy Lists - User Mobility - Voice Mail - Call Center - Multimedia Conferencing - Instant Messaging - Games - and many more. In the OSI -model, SIP is used as a signaling protocol. SIP can use either UDP or TCP as a transport protocol. In both cases, it is addressed over the port number 5060. To disclose details of the media's user data transport, SIP uses the SIP Session Description Protocol (SDP). RTP, the Realtime Communication Transport Protocol, is deployed for voice transport. The port numbers and Codecs used are also transmitted via SDP. The Voice-over-IP Standard H.323 also uses RTP in order to transport user data. The content-type of the SIP Header is given as 'application/sdp'. 'voice parameters' are provided in the Session Description Protocol (SDP). The MIME relationship of the code, enabling the smooth extension of additional services, becomes obvious here. The 'Call-ID'-header identifies the session. A 'Call-Leg'-session is opened, which remains the same during the entire session and which contains the statements 'Call-ID', 'From' and 'To'. The sender (addresser) field in the 'BYE'-message lists Marconi as initiator whereas the 'Call-Leg' remains the same, because it identifies the session. The 'BYE'-message is an independent message.

Only the 'Via'-header is modified. Every SIP component that initiates or routes a message is listed in the top line of the 'Via'-header.

Registration of SIP Clients A SIP Proxy server can only work with clients whose addresses it knows. However, addresses can vary in the IP world, and therefore clients must register with their SIP URL at the SIP Proxy server when starting their SIP application.

The SIP Proxy that takes over this function is called the 'Registrar'. How and where the 'Registrar' stores its data is up to the manufacturer. Protocols like LDAP might be used, for example.

Example SIP Registration "200 OK"-Message The information that client "tesla@highvoltage.org" can be reached at the IP address 192.168.0.1 is saved by the 'Registrar' in the connected database.

To confirm the data storage, a '200 OK'-message is sent to the client that confirms registration. From now on, Tesla is identifiable through his SIP URL and can be reached by everyone. SIP Components: Sip Clients As you've already seen, a SIP client can be - a hardware-client, such as the optiPoint 400 standard SIP V2.0 from Siemens, - a software-client, like Microsoft Messenger, but it could also be - an application, for example a gateway, that translates between the different network topologies SIP and ISDN. Every SIP client is controlled with an agent software. The SIP user agent consists of two components: the User Agent Client (UAC) and the User Agent Server (UAS).

Both components are used during a SIP session. The User Agent Client (UAC) places requests, for example an 'INVITE' or 'BYE' message, whereas the User Agent Server (UAS) responds to incoming requests. SIP Clients- The starting point of any communication in a SIP network is the client. SIP Gateways The SIP gateway is an application that connects the IP -based SIP network with other network topologies, for example with the Public Switched Telephone Network (PSTN). For the SIP protocol, the SIP gateway is a sort of special user agent that responds to a protocol instead of a person. SIP gateways can serve the following protocols, depending on the area of application: - SIP and ISDN - SIP and H.323 - SIP and SS7 SIP Server Types SIP servers are actually applications that receive and answer SIP requests. There are different types of SIP servers. They are logical entities that can be installed simultaneously on the physical SIP servers of various manufacturers.

Common SIP server types are: - SIP Proxy Server - SIP Registrar - SIP Redirect - SIP Forking Proxy. SIP Server Types SIP Proxy-Server SIP Proxy servers are different from other SIP components in two points: 1. SIP Proxy servers have no media capabilities. 2. SIP Proxy servers only answer requests from clients, but they never place their own requests. An exception to this rule is the 'CANCEL'-message.

In order to be able to serve SIP clients, the clients must be logged in and registered. The server enabling registration is called the 'Registrar'.

SIP Gateway

SIP SERVERS

A whole selection of third party applications complete the scenario. They might include - Voicemail, or - Billing- and - Accounting Systems. When the client registers with the 'Registrar', the 'Registrar' enters the log-in in the connected database. SIP Proxy Modes The SIP Proxy can be configured in different modes.

A Stateless Proxy is a logical instance which does not record status information about its SIP transactions. The Proxy forwards every request and every response in this mode. In the Stateful Proxy mode, on the other hand, the Proxy monitors the condition and the status of a transaction throughout the entire duration of the call.

This mode is also known as Transaction Stateful Proxy Mode. The 'Forking' Proxy takes on a special role. In cooperation with the Registrar, this mode allows for multiple registrations. This means user agents can log in on the same SIP Registrar/Proxy under the same name from multiple IP addresses. SIP Forking Proxy Login In our example, Marconi logs in with his SIP URL 'marconi@radio.org' on three different clients. Using the SIP header, the Registrar enters three different IP addresses in the database under 'marconi@radio.org'. If Marconi is called by another user, the following happens: The SIP Proxy receives an 'INVITE' for the URL 'marconi@radio.org' The Proxy server searches the database for entries for the user "marconi@radio.org" and discovers that "marconi@radio.org" can be reached at the IP addresses: 10.1.1.1, 10.1.1.2 and 10.1.1.3. Now the Proxy sends an 'INVITE' message to all of the supplied IP addresses. This process is called 'forking'. It enables Marconi to receive a parallel signaling of a call on multiple end machines. The SIP Redirect server provides the 'Call Forwarding' function. It is a special form of the Proxy server that answers a request but doesn't redirect it. Instead, the server returns the new destination address (URL) to the client. User Authentication: Authentication consists of three elements: - the SIP user name,

- the SIP password, - and the SIP Realm, the so-called SIP area, which is comparable with a domain or an H.323 zone.

SIP Messages The SIP messages consist of requests and responses. Every request -except for 'CANCEL' - is answered with a confirmation. The SIP request messages are: REGISTER : The user registers with the Proxy server. INVITE : Session request of a client. ACK : Confirms the receipt of an 'INVITE' request. BYE : Ends a session. CANCEL : Ends a session that was not yet set up completely. OPTIONS : Transmits additional information. This message is accepted by clients, but not transmitted. Other messages, that supplement the IETF standardized messages, are: SUBSCRIBE, NOTIFY, INFO, REFER and MESSAGE.

SIP Addressing The following address formats are supported:

FQDN Resolution DNS: USED TO FIND THE SIP proxy server for a particular domain.

E.164 Resolution 1) Since most users are comfortable with telephone numbers, the use of E.164 numbers is a practical choice. When a user chooses the telephone number '089/72232022', the default domain or his IP address is automatically attached. In this case, the telephone number is converted into the address '08972232022@avodaq.com'. The SIP Proxy supplements the telephone number by the official, canonical format '+498972232022@avodaq.com' and forwards the message. 2) In order to send the message to the right addressee, the SIP Proxy must be informed about the call number plans of other SIP proxies. This information is provided by the 'Telecommunications-Routing over Internet-Protocol' (TRIP), which is standardized in RFC 3219. Via this TRIP protocol, the SIP Proxy of the Avodaq company learns that the selected call number range is administered by the SIP Proxy 'sip.siemens.de'.

3) The SIP Proxy 'sip.avodaq.com' routes the 'INVITE'-message to the client's address over 'sip.siemens.de'. The message is received. However, if no user is found with this number at 'sip.siemens.de', the number will be re-converted into the international format and sent to a gateway that relays the data to a PSTN. By the way, not every manufacturer supplements the address format!

ABNF versus ASN.1 The encoding scheme used by H.323 is ASN.1 PER, a binary database description language that can do with as few bits as possible for the transmission of a data field.

Due to the structure of ASN.1 it is difficult to implement additional functions and services without changing the binary stack. In order for H.323 messages to be decoded, a special software package must be used. SIP, on the other hand, works with the text-based ABNF encoding scheme that is very flexible. The Parser Logic is based on HTTP and can be implemented in simple text-based programming languages such as Perl. Because the SIP header and parameters are transmitted as true text data, every packet sniffer can also display SIP packages, except when they are encrypted.

For signaling transport, SIP uses UDP or TCP, whereas H.323 only uses TCP. SIP supports conferencing via IP multicast without an additional server; H.323, on the other hand, always needs a Multi Control Unit (MCU). SIP is text-coded while H.323 is binary. SIP utilizes different server types for particular functions while H.323 handles all functions over a gatekeeper, which makes it only partly scalable. The greatest difference between H.323 and SIP refers to Internet services, not to telephone services. In the future, many new Internet services will be oriented toward SIP.

Advantages of SIP 1) SIP is a 'young' protocol without the burden of older telecommunications protocols. 2) SIP was developed by the Internet Developer Community and is based on successful, scalable Internet protocols. 3) SIP is a light-weight, ASCII -based protocol that is easy to implement and expand. 4) SIP regulates very little and places no restraints on the media employed. 5) SIP is not limited to voice or video; instead, it is a multi-communications protocol.

optiPoint 400 SIP Version 3.0. Microsoft Office Live Communications Server 2003 Siemens HiPath OpenScape In both environments, the optiPoint 400 SIP acts as end point. The optiPoint 400 SIP V 3.0 supports of course the SIP (Session Initiation Protocol) as per current RFC 3261 standard, the SDP (Session Description Protocol), and the subordinate protocols TCP (Transmission Controll Protocol) and UDP (User Datagram Protocol). File transfer is handled via FTP (File Transfer Protocol), management tasks via SNMP (Simple Network Management Protocol) and time synchronization is performed using the SNTP (Simple Network Time Protocol). Web interfaces are displayed via HTTP (Hypertext Transfer Protocol), whereas voice packet transmission uses the RTP (Realtime Transport Protocol) and RTCP (Realtime Transport Control Protocol). Name resolution is performed via the DNS (Domain Name Service), and the basic configuration can be carried out via DHCP (Dynamic Host Configuration Protocol). Last but not least, Quality of Service is supported on OSI layer 3 according to the DiffServ model and on OSI layer 2 according to IEEE 802.1p/q. DHCP Numerous basic configurations can also be distributed automatically using the DHCP protocol. These basic configurations include: IP address and sub-net mask, definition of default and static routes, and additional information such as SNTP and time zone and DNS server IP address. Additionally, one can also assign the SIP server addresses via DHCP. Distribution of VLAN information to the individual telephones is ensured with the Siemens "Vendor Unique" DHCP Option 43.

On the following pages you will be introduced to the configuration options of optiPoint 400 SIP relating to the: telephone Menu DHCP Web interface Openscape management console Telephone Menu

Like all the previous optiPoint 400 versions, the SIP Version 3.0 also has a built-in flexible configuration menu allowing telephone installation and feature specification to be carried out directly on the device. DHCP Numerous basic configurations can also be distributed automatically using the DHCP protocol.

These basic configurations include: IP address and sub-net mask, definition of default and static routes, and additional information such as SNTP and time zone and DNS server IP address. Additionally, one can also assign the SIP server addresses via DHCP.

Distribution of VLAN information to the individual telephones is ensured with the Siemens "Vendor Unique" DHCP Option 43 Web interface The configuration page of the telephone can be reached via standard Internet browsers such as the Internet Explorer from Microsoft. OpenScape Management Console The OpenScape Management Console is a plugin for the Microsoft Management Console (MMC), which was introduced with the Windows 2000 Server. Here, one can and even must configure the optiPoint 400 SIP Version 3.0, provided it shall be integrated in the Siemens OpenScape infrastructure.

A sample configuration of optiPoint 400 with the OpenScape Management console. 1. Starting point of telephone installation 2. Global configuration: (general:system config, SNMP, QoS), (Profile:DNS, enter network-specific settings, Kerberos authentication, country settings, VoIP parameters, and system-wide telephony settings.), (Security:UN, PW) 3. Configuration of individual phones 4. Registration of individual phones Configuration of individual telephones

As mentioned previously, all the phones that were identified but not yet assigned to a specific user are listed in the "Unassigned Phones" area. Right-clicking the selected telephone opens up the context-sensitive menu. To carry out the configuration you have to choose the Assign item. Telephone registration Provided the password of the OpenScape user was correct, the phone will now be listed as registered device.