throbber
Sametime Unified Telephony 8
`
`
`Session Initiation Protocol (SIP)
`
`
`
`
`
`This chapter provides information on the following topics:
`
`•
`SIP Overview
`
`•
`Using SIP in the Media Server.
`
`SIP Overview
`The SIP communication protocol was developed by the IETF as application layer protocol. It originally realized the
`signaling of IP-based voice transmission, but has in the meantime been expanded for applications in the areas video
`and instant messaging. Since SIP within this scope only realizes the signaling of connections, it uses various other
`protocols for the actual transmission of usable information. This includes e. g. the RTP protocol used for transmitting
`real-time data.
`In the voice area, SIP enables all basic call functions such as connection set-up and shutdown, call notification or dial
`tone. Beyond that, further features are already implemented in SIP. Among these are the features parking, call
`transfer or conference switch. Considering the supported features, SIP can by now be compared with H.323.
`Contrary to H.323, the SIP communication model realizes a big part of the functions in the terminal device. This
`significantly differentiates it from the traditional communication concepts in which the actual intelligence lies in the
`network nodes.
`
`SIP Network Components
`An SIP network consists of different SIP-specific logic components. These intercommunicate in a defined way.
`
`The logic components of an SIP network are:
`
`•
`User Agent (UA)
`The user agent represents the terminal device in an SIP network. It signals and manages SIP
`connections that it initiates with other user agents1 or proxy servers. Upon logging in at an SIP network a
`user agent registers with the registrar server in charge.
`The user agent is logically divided into the user agent client and the user agent server. The user agent
`
`
`
`Petitioner Apple Inc. - Exhibit 1081, p. 1
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`•
`
`•
`
`•
`
`
`
`
`
`
`
`•
`
`client is in charge of initiating SIP connections. The user agent server replies to connection requests.
`User agents are e.g. SIP telephones or an SIP client software.
`Registrar Server
`Registrar servers are responsible for registering user agents. The information collected during the logging
`of the single user agents are transferred to the location server that administer these data for future
`requests.
`Registrar servers often operate on the same platform as the associated location server (see below).
`Location Server
`Each SIP domain has a location server. This server administers e.g. information on the bindings of logical
`and physical SIP addresses (cf. Section "Addressing an SIP subscriber").
`Location servers often operate on the same platform as the associated registrar server (see below).
`Proxy Server
`Each SIP domain has a proxy server. This server receives the connection requests by user agents or
`other proxy servers. The proxy server is logically divided into a client and a server component, which
`perform individual connection requests on behalf of user agents.
`With handling a connection request, two cases must be differentiated:
`The communication participants are in the same SIP domain
`-
`In this case only the proxy server of the domain concerned is involved in the connection
`establishment.
`The communication participant is in different SIP domains
`In this case the two proxy servers of the domains concerned are involved in the connection
`establishment.
`For the resolution of SIP addresses the proxy server communicates with the associating location and
`redirect server.
`Redirect Server
`A redirect server processes proxy server requests as regards configured call reroutings for user agents. It
`operates domain-spanning.
`For the resolution of SIP addresses the redirect server communicates with the associated location server.
`
`-
`
`
`Addressing an SIP subscriber
`SIP addressing is based on a logical and a physical2 SIP address. The logical address is assigned to the person
`"user", the physical address is allocated for the device, with which the user registers with the registrar server. The
`actual routing within an SIP network occurs based on the physical address.
`Example:
`
`
`
`User Martin has in our example the logical address Martin@MyDomain.com. Under this address he is to be
`addressed in the entire SIP network. His physical address, according to which messages are routed for him in the
`network, depends on the terminal device with which he registers in the SIP network. In our example Martin registers
`with a laptop. This laptop has the physical addressLaptop31@OtherDomain.com.
`If another SIP subscriber wants to establish a communication relation to Martin, he/she addresses the connection
`setup with the logical destination address Martin@MyDomain.com. This makes sense since the SIP users do not
`know via which terminal device a subscriber registers. In the course of the connection setup this logical address is
`resolved by the location server into the current physical address.
`
`Interaction between logical SIP Components
`The interactions between the logical SIP components are based on various transactions. These consist in each case
`
`Petitioner Apple Inc. - Exhibit 1081, p. 2
`
`

`
`of
`a request sent by an SIP client to an SIP server
`•
`
`an associated reply sent by an SIP server to an SIP client
`•
`
`Let's take a look at two simple examples to describe the general interactions between the SIP components to
`establish a connection between two user agents. For reasons of simplification we discount the registrar and redirect
`server function.
`The first example describes the connection establishment between two agents that are in the same SIP domain. In
`the second case the user agents involved are in different SIP domains.
`
`Connection between two Subscribers in one SIP Domain
`Let us see how a SIP connection is established between two SIP clients that are in the same SIP domain.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`6.
`
`User-agent A initiates a connection to user-agent B. For this purpose he/she sends a corresponding
`connection request to the proxy server of the domain. The connection request contains the logical SIP
`address of the destination party - Agent_B@Domain.com.
`The proxy server requests the registered address information of the destination subscriber from the
`location server.
`The location server replies to the proxy server with the physical SIP address of the destination
`subscriber.
`Subsequently, the proxy server resolves the received SIP address into an IP address via the DNS server
`in charge.
`The proxy server sends an individual connection request to the IP address of user-agent B.
`User-agent B replies to this request and informs the proxy server that he/she accepts the requested
`connection.
`The proxy server correspondingly accepts the original connection request of user-agent A (see 1).
`User-agent A then establishes a direct RTP connection to user-agent B.
`
`7.
`8.
`
`
`
`
`Connection between two Subscribers in different SIP Domains
`The following example shows the general structure of an SIP connection between two subscribers in different
`domains.
`
`Petitioner Apple Inc. - Exhibit 1081, p. 3
`
`

`
`3.
`4.
`
`User-agent A initiates a connection to user-agent B. For this purpose he/she sends a corresponding
`connection request to proxy server A of his/her own domain. The connection requests contains the logical
`SIP address of the destination party - Agent_B@Domain_B.com.
`By the domain name of the destination address Domain_B.com , proxy server A recognizes that user
`agent B does not belong to the own domain A. Subsequently, it queries the IP address of the proxy
`server responsible for domain B at the DNS server in charge. Thus the IP address of proxy server B.
`Proxy server A sends an individual connection request to proxy server B3.
`Proxy server B then requests the SIP address under which the destination subscriber is registered in the
`SIP network from the location server in charge.
`The location server replies with the physical address of the destination subscriber.
`Subsequently, the proxy server resolves the received address into an IP address via the DNS server in
`charge.
`Proxy server B now sends an individual connection request to user-agent B.
`User-agent B replies to this request and informs proxy server B that he/she accepts the requested
`connection.
`Proxy server B accepts the connection request by proxy server A (see 4).
`9.
`
`10. Afterwards, proxy server A accepts the connection request by user-agent A (see 1).
`
`11. User-agent A then establishes a direct RTP connection to user-agent B.
`
`You find further information on SIP in the appropriate literature or in the relevant RFC standards of the IETF
`(www.ietf.org).
` 1A communication connection between two user agents is directly established via RTP.
`2The physical SIP address is not to be confused with an address of the physical OSI layer.
`3Consequently, proxy server A becomes the Outbound, proxy server B the Inbound proxy server.
`
`IBM® Lotus® Sametime® Unified Telephony 8
`Trademarks | Submit Feedback
`
`
`
`Top
`
`
`
`
`
`1.
`
`2.
`
`5.
`6.
`
`7.
`8.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Petitioner Apple Inc. - Exhibit 1081, p. 4

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket