This presentation discusses the new support for the session initiation protocol in WebSphere Application Server V6.1.

Transcription

1 This presentation discusses the new support for the session initiation protocol in WebSphere Application Server V6.1. WASv61_SIP_overview.ppt Page 1 of 27

2 This presentation will provide an overview of the session initiation protocol and WebSphere SIP support. It will also cover how to develop and troubleshoot SIP applications. WASv61_SIP_overview.ppt Page 2 of 27

3 The first section provides and overview of SIP. WASv61_SIP_overview.ppt Page 3 of 27

4 SIP is a lightweight, extensible communications protocol. SIP was first formalized by the IETF in 1999, and was revised in RFC 3261 is the core SIP RFC, and it is fully supported by WebSphere Application Server V6.1. Generally, SIP is used to negotiate a call between two endpoints. SIP negotiates the medium, the transport, and the encoding for the call. The medium might be text, voice, or some other type of media; the transport mechanism could be UDP, RTP, TCP, or some other protocol. Once the SIP call has been established, the communication takes place over the specified transport mechanism, independent of SIP. WASv61_SIP_overview.ppt Page 4 of 27

5 SIP and its extensions are a key element of many new applications, especially when converged with HTTP. The telecommunications industry is rapidly moving to SIP, and several current SIP applications involve telephony systems, such as voice over IP. Clickto-call applications might allow you to click to start a conversation with a support specialist. Registration allows a SIP endpoint to register with a SIP registrar so that other SIP endpoints can find it. For example, logging in to an instant messaging client and then showing up as being online is an example of registration. Presence information describes a user s ability to communicate across endpoints. This is like knowing whether your online buddy would like not to be disturbed or whether she is available to chat. WASv61_SIP_overview.ppt Page 5 of 27

6 SIP is certainly not the only signaling and peer-to-peer technology available, but there are several benefits associate with using SIP. Since it is text based, SIP is flexible and easy to extend. The protocol is also lightweight, efficient, stable, and offers several security features. Standardization and interoperability are two of SIP s major advantages over other protocols. The entire telecommunications industry is adopting SIP, and vendors are serious about interoperability and meet regularly to test their products together. These events are called SIPit which stands for SIP Interoperability Tests. The standards surrounding SIP including RFCs 3261, 3262, and JSR 116 help facilitate interoperability. WASv61_SIP_overview.ppt Page 6 of 27

7 SIP messages are simple text-based requests and responses used to negotiate a SIP call. These messages consist of an envelope and an optional payload. The two messages above illustrate the beginning of a call sequence. To start the call, an invitation is sent, and the response indicates that it is ok to begin a call. The first line of the INVITE message is called a request line, and the first line of the response message is called the status line. WASv61_SIP_overview.ppt Page 7 of 27

8 The request line of the first message contains a lot of information about the call. The type of message being sent, or the method, is INVITE. This line also contains the request URI, which is the location to which the request will be sent, and the SIP version being used. SIP 2.0 is the most recent SIP version. The status line of the response message also contains SIP version information, and a status code and a reason phrase. In this example, you are willing to accept the call invitation, so you respond with a 200 OK message. Recall that, while SIP messages specify a signaling protocol for negotiating calls, the messages themselves are sent over a separate communication protocol. The transport protocol being used UDP in this example is indicated in the SIP messages. WASv61_SIP_overview.ppt Page 8 of 27

9 This diagram shows the structure of a SIP call in which intermediate proxy servers are used to forward requests and responses between the two SIP clients. The correct sequence of messages between the SIP clients and proxies is defined in the RFCs provided by the IETF. It is possible for SIP endpoints to communicate directly with no proxy servers involved. In that case, the boxes and arrows in orange describe the structure of the handshaking surrounding the SIP call. Once the call has been established, communication takes place directly between the two SIP clients. The clients also negotiate the call disconnect. WASv61_SIP_overview.ppt Page 9 of 27

10 The following section describes the architecture of WebSphere Application Server s SIP support. WASv61_SIP_overview.ppt Page 10 of 27

11 The SIP container and SIP proxy are part the WebSphere Application Server core product, and so they are present in every WebSphere Application Server installation. When you create an application server profile, it includes a SIP container. A SIP application must be installed for the SIP container to start and listen on its ports. The three core components of WebSphere s SIP architecture are the SIP container, SIP proxy, and load balancer or IP sprayer. WASv61_SIP_overview.ppt Page 11 of 27

12 The SIP container is an extension of the existing Web container. It implements the JSR 116 SIP servlet specification and also contains a SIP protocol stack that implements all of the pertinent RFCs. The WebSphere SIP proxy is an edge component that directs SIP messages to the appropriate container. This proxy handles both SIP and HTTP requests. The term 'SIP proxy' is used 2 ways within WebSphere and the larger SIP world. The stateless edge device SIP proxy exists only to route messages to clusters of SIP containers and balance the load across those containers. A SIP proxy application is an application that runs in a SIP container and implements what is defined in RFC The load balancer handles IP spraying to a cluster of proxies. The proxy and the load balancer used to support SIP are the standard proxy and load balancer that come with WebSphere Application Server. These components play an important role in supporting SIP, but they are not specialized for SIP. WASv61_SIP_overview.ppt Page 12 of 27

13 Developing, deploying, and administering converged applications is simple because the SIP container was built as an extension of the existing Web container. Converged applications consisting of HTTP and JSR 116 SIP servlets and JSR 168 portlets can be deployed to the container. A SIP application, sometimes called a SIP proxy, is an application that contains at least one SIP servlet. SIP applications must behave according to the standards supplied by the IETF. SIP servlets are similar to HTTP servlets in their request and response structure, but SIP servlets are also asynchronous and bidirectional. WASv61_SIP_overview.ppt Page 13 of 27

14 You can configure the behavior of the SIP container through the administrative console. This behavior falls into three categories: transport chains, general container properties, and session management. A transport chain is a configurable representation of the SIP protocol stack. Configuring transport chains allows you to control the addresses, ports and protocols over which the container or proxy will communicate. There are three inbound transport chains defined: default, secure default, and default UDP. These are all enabled by default. Many general properties of the SIP container can also be configured in the administrative console. For example, the maximum number of connections and messages the container will manage, the behavior of the container when any maximums are exceeded, the interval at which the container calculates averages and publishes statistics to PMI, and the thread pool to use for the container. The session management attributes for the application server apply to both HTTP and SIP. WASv61_SIP_overview.ppt Page 14 of 27

15 A virtual host alias must be defined for each port on which the SIP container is listening for messages. If the virtual host is not configured correctly, SIP messages will not be received by SIP applications. The default_host has ports 5060 and 5061 configured by default. No virtual host definition is required for the SIP proxy. The host can be configured in the administrative console. WASv61_SIP_overview.ppt Page 15 of 27

16 Each replication domain should be associated with no more than three SIP containers. If you configure your environment using those guidelines, you will have better performance. When you configure your replication domain, you should use the following properties: the domain should be set to Entire Domain, the replication mode should be Both client and server, and the container s distributed session needs to be set to Memory-to-memory replication. These settings are configured under Session management in the administrative console and are used for both SIP and HTTP. WASv61_SIP_overview.ppt Page 16 of 27

17 Like the SIP container, the WebSphere SIP proxy is also converged and handles both SIP and HTTP requests. The WebSphere SIP proxy is a an edge component that handles routing SIP messages to the appropriate container; this is different than a SIP proxy application, which implements the standards defined by RFC 3261 and runs in the SIP container. The WebSphere SIP proxy fronts clusters either HTTP or SIP and handles application level failover, regardless of protocol. It handles session affinity and offers first pass protocol validation. The proxy also allows for augmentation by other products such as WebSphere Extended Deployment. WASv61_SIP_overview.ppt Page 17 of 27

18 The WebSphere SIP proxy needs to be configured with a default cluster to which it can route inbound messages that do not match any cluster routing rules. The default cluster can also be used when upgrading applications. To upgrade an application, add another cluster into your environment and make it the default cluster. Once all of the traffic is being routed to the new default cluster, you can safely update the applications in the original cluster without causing any disruptions. Cluster routing rules define how the proxy will route messages to different clusters in a cell, and they can be based on a variety of criteria, including the method type and the to and from fields. WASv61_SIP_overview.ppt Page 18 of 27

19 This diagram illustrates how cluster routing behaves. In this example, there are two SIP clusters, the support cluster and the sales cluster, which is the default cluster. The routing rules for each cluster indicate that they accept INVITE messages but there are restrictions placed on the to field. The proxy forwards message 1 to the sales cluster since message 1 matches the sales cluster s routing rule. Similarly, the proxy forwards message 2 to the support cluster since message 2 matches the support cluster s routing rule. Message 3, on the other hand, does not match the routing rule for either cluster, so the proxy forwards it to the default cluster, which is the sales cluster in this case. WASv61_SIP_overview.ppt Page 19 of 27

20 A collection of SIP clusters can be fronted by multiple SIP proxies, and the load balancer acts as a highly available IP sprayer that forwards messages to a SIP proxy. The load balancer runs a special application called a SIP advisor that communicates to a SIP advisor running in the SIP container. The SIP advisors talk to each other to maintain information on the status of the SIP proxies, and if the messages do not get through, the load balancer will continue looking for another proxy to filter the messages through. Proxies need to be configured so that they listen on the loopback address so that outgoing SIP messages are sent from the proper host address. WASv61_SIP_overview.ppt Page 20 of 27

21 Inbound messages come from the SIP client and are fed through the load balancer/ip sprayer interface to a SIP proxy. There may be many SIP proxies configured to front a set of SIP clusters. The SIP proxy then forwards the message on to the SIP cluster for processing, based on the cluster s routing rules. Once the message has been received by the SIP cluster, it is processed by the SIP container that has been mapped to handle that particular type of message. So, routing takes place at the proxy level to get to the appropriate cluster and at the container level to get to the appropriate SIP application. Outbound messages originate in the SIP container and are sent out from the SIP proxy, or the loopback interface. If MAC forwarding is enabled, the proxy will insert the load balancer s hostname into the via field of the outgoing message, even though the message does not actually travel through the load balancer on its way back to the client. WASv61_SIP_overview.ppt Page 21 of 27

22 External domains can be configured in the SIP proxy to facilitate routing to remote domains. These settings can be configured in the administrative console; the link is available on the proxy configuration page. You can configure several different properties for the external domain, including: Domain: the SIP domain that is mapped to the protocol, host, and port that is specified in the related fields of the configuration panel Protocol: the protocol used to make the SIP connection that is associated with the domain; the three possible values are TCP, UDP, and TLS Distinguished name: the name that is associated with the external domain; this is used when SSL client authentication is enabled to authenticate connections from an external domain, and the information center provides details on setting up secure connections between two domains Host: the remote host to use to create the SIP connection associated with the domain Port: the remote port to use to create the SIP connection associated with the domain WASv61_SIP_overview.ppt Page 22 of 27

23 The following section contains a summary and references. WASv61_SIP_overview.ppt Page 23 of 27

24 SIP is an open, standardized, lightweight, extensible communications protocol. It can be used to help build a variety of different applications, from voice over IP to instant messaging. The protocol itself provides a communication negotiation or signaling mechanism and the actual data gets sent using some other protocol, such as UDP. WebSphere Application Server V6.1 is the first release to support the session initiation protocol. The SIP architecture consists of three key components: the converged HTTP/SIP container, proxies, and load balancers. WASv61_SIP_overview.ppt Page 24 of 27

25 These are some useful links for information on SIP specifications and the SIPp test tool. WASv61_SIP_overview.ppt Page 25 of 27

26 SIP messages are grouped into categories by status codes. For example, a 180 RINGING message acknowledges that a request has been received but that additional processing is needed before a response can be sent. A 200 status code indicates OK that a message has been received and accepted. WASv61_SIP_overview.ppt Page 26 of 27

27 WASv61_SIP_overview.ppt Page 27 of 27