(12) United States Patent
`Nuutinen
`
`USOO6865681 B2
`US 6,865,681 B2
`Mar. 8, 2005
`
`(10) Patent No.:
`(45) Date of Patent:
`
`(54) VOIPTERMINAL SECURITY MODULE, SIP
`STACK WITH SECURITY
`MANAGER, SYSTEM AND SECURITY
`METHODS
`
`(75) Inventor: Mikko Nuutinen, Espoo (FI)
`(73) Assignee: Nokia Mobile Phones Ltd., Espoo (FI)
`(*) Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 726 days.
`
`(21) Appl. No.: 09/752,142
`(22) Filed:
`Dec. 29, 2000
`(65)
`Prior Publication Data
`US 2002/0129236A1 Sep. 12, 2002
`(51) Int. Cl." ......................... G06F 11/30; G06F 12/14;
`H04L 9/00; H04L 9/32
`(52) U.S. Cl. ..................... 713/201; 713/151; 379/395.6
`(58) Field of Search ................................. 713/201, 151;
`379/395.6
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`2002/0102999 A1 * 8/2002 Maggenti et al. ........... 455/518
`OTHER PUBLICATIONS
`“Signaling fir Internet Telephony” by H. Schulzrinne et al
`Proceedings of the Int. Conf. on Network Protocols, Feb. 2,
`1998.*
`
`ITU-T H. 323, Series H: Audiovisual and Multimedia
`Systems, “Infrastructure of Audiovisual Services-System
`snand Terminal Equipment for Audiovisual Services”,
`“Packet-Based Multimedia Communications Systems”,
`Feb. 1998.
`IETF RFC 2543, “SIP: Session Initiation Protocol', Hand
`ley et al, Nov. 24, 2000.
`“Signaling for Internet Telephony' by H. Schulzrinne et al
`Proceedings of the Int. Conf. on Network Protocols, Oct.
`1998, pp. 1–27.
`Internet Engineering Task Force Internet Draft Document:
`draft-Sinnreich-aaa-interdomain-sip-qos-osp-00.txt Jul.
`2000; Expires Jan. 2001; “AAA Usage for IP Telephony
`with Oos' H. Sinnreich et al.
`* cited by examiner
`Primary Examiner-Gilberto Barron
`Assistant Examiner Joseph McArdle
`(57)
`ABSTRACT
`A secure voice over internet protocol (VoIP) terminal
`includes a modular Security manager for use in conjunction
`with a protocol Stack thereof, wherein the Security manager
`includes a plurality of interfaces to the stack. In an SIP
`embodiment, these may include a Security Stack interface
`(SSA) between an SIP manager of an SIP stack and the
`Security manager, a Security terminal interface (SST)
`between a telephony application and the Security manager, a
`security media interface (SSM) between the security man
`ager and a media controller, and a Security manager appli
`cation interface (SMA) between the Security manager and a
`security application (PGP) outside the stack.
`8 Claims, 15 Drawing Sheets
`
`Application Interface -...-a, -i-...--or-o-o-o-oner
`Application interface implementation
`
`isP Stack
`
`
`
`
`
`Sip Manager
`
`Media Cntrl
`
`- Network Interface
`
`1
`
`Comcast, Ex. 1135
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 1 of 15
`
`US 6,865,681 B2
`
`
`
`Endpoint 2
`
`FIG. 2
`
`2
`
`

`

`U.S. Patent
`
`
`
`
`
`US 6,865,681 B2
`
`9. "OIH
`
`XXO? Hd d1S OSW
`
`3
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 3 of 15
`
`US 6,865,681 B2
`
`
`
`
`
`
`
`LOENJIGJEMTCHIS OSW
`
`4
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 4 of 15
`
`US 6,865,681 B2
`
`
`
`(SI) K3SI
`
`S "OIH
`
`
`
`5
`
`

`

`US. Patent
`
`Mar. 8, 2005
`
`Sheet 5 0f 15
`
`US 6,865,681 132
`
`stow58$Em
`
`<Ema
`
`nutmmm—Hm
`
`<5m:
`
`
`
`3:33..:o:«~:o£:<585Inow
`
`
`
`
`
`:.Hogwoccofisax$xo€
`
`
`
`...Eonfitofi:<$xo€
`
`WEE/S
`
`52me
`
`bfio:55:<-333
`
`
`
`855552:1:3
`
`
`
`...”cocamtofiaq‘
`
`
`
`.Bfimom
`
`MOcom
`
`
`
`Samoan?xcosmosh
`
`«€62
`
`955::
`
`8on~.Zm< ismwéacmaRm:6.6%mczaimam
`.8805 ooflBEH
`cosmozmmxx
`
`
`
`socombmnmuoxoom
`
`SEEEm
`
`oofl.3£
`
`
`
`Surat:x8332
`
`\l.05
`
`w.95
`
`6
`
`
`
`
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 6 of 15
`
`US 6,865,681 B2
`
`Application Interface - i.e.--...--.
`Application interface implementation
`
`SIP stack TT
`
`
`
`Sip Manager
`
`Media Cntrl
`
`FIG. 9
`
`Network wrapper / Parser
`
`r Network Interface
`
`
`
`
`
`
`
`
`
`
`
`FIG, 12(b)
`
`FIG. 12
`
`FIG. 13(a
`
`FIG. 13(b)
`
`FIG. 13
`
`7
`
`

`

`U.S. Patent
`US. Patent
`
`Mar. 8, 2005
`Mar. 8, 2005
`
`Sheet 7 of 15
`Sheet 7 0f 15
`
`US 6,865,681 B2
`US 6,865,681 B2
`
`
`
`
`
`CmmvoomYBEREESEBisoom............
`
`€meEm
`
`u___
`
`
`
`Ema8%?£82259%.......................swag:9m"V_
`
`bflsoomnu_$52a,m.£58m.fl__
`Homwcag
`
`3.6$622"
`
`m
`
`
`
`
`
`
`
`
`
`
`
` :.:5.1.1.1...::.:....::.....:.::.::::-..::53}.x....:...........:.:2...:....:.1.:.x..MONWHQHCHCOMHmoM—QQ<
`
`
`
`
`
`03:85#8332...........................................................................................................................
`
` oomtflfixAgmvmomtogficosmomamdflmMumum2.58m
`
`
`
`x5352 m:Gamma
`"fl
`
`Swan\5&3?
`
`__._
`
`8
`
`

`

`U.S. Patent
`US. Patent
`
`Mar. 8, 2005
`M
`28,
`
`Sheet 8 of 15
`.bM00m
`
`US 6,865,681 B2
`US 6,865,681 132
`
`
`
`
`
`uwmmmoE63:00Em
`
`£58m@565;mowmmmoe35:8Em
`
`axofim
`
`
`
`
`5.2m $9252
`
`bisoom:23wczficwfi
`
`.aosfiEEQE“$882
`
`
`
`
`wing;EmmcmEbusuom50:23wczacwmm
`53:32
`uwmmmoE
`£23355?
`
`96m98368m
`
`ucumnewozwoom
`
`[ [ "OIH
`
`Z.05
`
`
`
`9
`
`

`

`US. Patent
`
`Mar. 8, 2005
`
`Sheet 9 0f 15
`
`US 6,865,681 132
`
`Emcfismc:5..
`
`mE>z_................592923:886.06
`
`
`
`nmumNtocfimcstSvdom
`
`
`
`gwas“6.32053a6:mm;835
`
`8:32mm;>==omamo>25omm$m“mm
`
`
`
`mwmoosw02mm<3<30mm092
`
`
`
`
`
`mamozcmcufiam:>>>>3Ucww
`
`
`
`02.5....00—<3295m83.8m_zEmumNtocSm
`
`€w~co£s$w....>z_
`
`\\\\\\\\\\\\\\\\€80526:20:2:
`
`mmwwmmznzwlfizofizmnmmm
`
`mammmmEEmHaaocmtmmm
`
`alabocmlme
`
`INT—053$ImEm
`
`m@3826..mvmymozcmzsmlmwm
`
`womwmmZEwlabomnlmmw
`BmozcwcsmlmEm
`
`mgumwooamuoEEImQC
`
`
`
`IIIIII’IIIIIIIIIIIpI'IIIIIIIIIIIllllllllul'l-Illlllll'llullllllllIIII'lI
`
`10
`
`10
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`US. Patent
`
`Mar. 8, 2005
`
`Sheet 10 0f 15
`
`US 6,865,681 132
`
`
`
`OZOZEoww
`
`m>=o<=momo:
`
`mommmmEEwIancmxmmw
`
`mommwm§m_mtmNto£:mxmwm
`2111‘]
`3:053;me
`“abocmme
`
`11
`
`Egg.0:
`
`mEthQoEQImo:
`
`
`
`wmmmmeEwiabomntmmm
`
`mmmwmeEwlmwmozcmézmlmmm
`Bmozcmcfimlme
`
`“abomnumEm
`
`umfimccoomgoEEImoc
`
`mammmeEmlaaomurmmw
`
`
`gamma—2a_w1$mo_EmcSwImwm
`Emu=cm£=mlmEm
`
`330%!me
`
`
`
`11
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 11 of 15
`
`US 6,865,681 B2
`
`
`
`
`
`BLIANI
`
`36esseWEIST??eo?ue?neTess
`
`
`
`BLIANITOEZI HOHLAVTLIVM
`
`
`
`
`
`- - - - , - - - ~~~~ ~~~~ -u6uW Á?unO3Sd€)d
`
`ddy
`
`
`
`SSHOOTIS SON|WOONI \/[\ \/[^ OES OSW
`
`
`
`
`
`12
`
`

`

`US. Patent
`
`Mar. 8, 2005
`
`Sheet 12 0f 15
`
`US 6,865,681 132
`
`mc_Eooc___monoc
`mommmw1m8.5salmmmiE..65
`AmammmeEmlmEocimlmmm:
`
`
`GZGZEom:m~=o£=mlmsm
`
`02;”;o3wwcofismwimem
`v.0oommNtofizmszm
`
`mammmmEEwHabocmmmm
`wmmmmeEmlfibocwlmwm
`mammmw2a_mlmw_._o£:mlmmm..
`
`
`
`Isabocmme
`
`6263.60-82
`
`
`
`mmmwwwfin.anabomotmmm
`
`330%mEm
`
`SmozcmfismImEm
`
`13
`
`
`
`mammwmégmdaaocwmmm
`
`mammmememNtocSmxmmwI
`
`:5on95
`
`250:0me
`
`35:56
`
`13
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 13 of 15
`
`US 6,865,681 B2
`
`Security Manager
`
`
`
`1(3)
`
`Receiving terminal
`Security Manager receives
`an invite. The security parameters
`are checked and new invite is
`requested.
`
`sip invite
`
`TASK Security Manager
`invite
`
`TASK SecurityManager
`Send WWW auth
`
`
`
`
`
`
`
`wait auth invite
`
`FIG. 14(a)
`
`14
`
`

`

`U.S. Patent
`US. Patent
`
`Mar. 8, 2005
`
`Sheet 14 0f 15
`
`US 6,865,681 B2
`US 6,865,681 132
`
`
`
`
`
`
`
`_mc_E§mc_>_momm..I
`
`ESE53mto;
`
`
`
`
`
`w:.>:_l£:m1:m>>REESm:_>_momm
`
`
`
`ummmcmémwrwmmm
`
`_
`
`_Lotwdom
`
`memcmibrzowwrxw/fi
`
`8:01
`
`.omficm;vcm828m:28:0c<ESEuchocSm
`
`
`
`353$9892Zzsomw
`
`5amcméésowmuxm5
`2353m:9:BEBmEEma
`
`3.53%mg....8282223E3m:ucm2282.2:
`
`85553cm329262
`
`$32:
`
`.oSSEcamcmxomco2m
`
`.xoSw052E32.95
`
`15
`
`
`
`
`
`mm:.39923.58m
`
`.959
`
`.wmmcm2>«::omwlxm<._.
`
`
`
`23:33
`
`wt>E85553::835nmNtofizm
`
`
`
`15
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Mar. 8, 2005
`
`Sheet 15 of 15
`
`US 6,865,681 B2
`
`
`
`Security Manager
`
`Sending terminal
`The terminal has sent an invite and
`received 401 Unauthorized
`response. It makes new authorized
`invite messages and sends it.
`
`got unauthorized
`
`TASK Security Manager
`authorization reqd
`
`send auth invite
`
`16
`
`

`

`US 6,865,681 B2
`
`1
`VOIPTERMINAL SECURITY MODULE, SIP
`STACK WITH SECURITY
`MANAGER, SYSTEM AND SECURITY
`METHODS
`
`TECHNICAL FIELD
`The present invention relates to internet telephony (VoIP)
`and, more particularly, to providing for a Secure VoIP
`terminal.
`
`DISCUSSION OF RELATED ART
`In the last few years, the intemet has become a feasible
`infrastructure for Supporting various multimedia Services.
`These include interactive Services Such as IP telephony, also
`known as Voice over Internet Protocol (VoIP). VoIP can be
`defined as the transport of telephony calls over an IP
`network. In contrast to traditional telephony, where an
`end-to-end circuit is set up between two endpoints, IP
`telephony uses the intemet protocol to transmit voice pack
`ets over an IP network. The addition of voice to the data
`network also generates new possibilities, Such as new inte
`grated Services that are not used over a traditional circuit
`Switched network, i.e. data and Video communication. Over
`public networks, like the intemet, the benefits of IP tele
`phony are currently limited by the marginal Support for
`Quality of Service (QoS), inadequate traffic management
`and the lack of Security. Thus there are still Some technical
`issues to be improved to ensure comparable usability with
`Public Switched Telephone Network (PSTN).
`VoIP security is one of the major technical issues that has
`to be defined before VoIP could be used in public networks
`like the internet. Internet telephony users do not want that
`calls could be listened in or Sensitive information, like phone
`numbers, passwords or credit card numbers, to be revealed
`to an unintended party. Thus not only the audio Stream needs
`protection, but the control Signalling requires to be Secured
`as well.
`There are currently two competing Standardized protocols
`for VoIP operation, ITU-T's H.323 and IETF’s Session
`Initiation Protocol. These two protocols describe Signalling
`and the control of multimedia conferences over packet based
`networks by different ways. H.323 is a part of a larger series
`of communication Standards called the H.32X Series and
`consist of many Subprotocols. SIP is a leSS complex text
`based client server protocol. At the moment SIP seems to be
`the major VoIP protocol for future services. However H.323
`has the advantage of better interoperability with PSTN and
`due longer development K has also many corporations
`backing it. There are many discussions and controversial
`predictions as to which approach will Survive. Although
`both standards may co-exist, only SIP is considered here.
`Although SIP is Specified quite well, it lacks a good
`specification of security. See Sections 13-15 of IETF RFC
`2543 “SIP: Session Initiation Protocol” by Handley et al.
`The present invention concerns a Suitable Solution for a
`Secure VoIP terminal.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`DISCLOSURE OF INVENTION
`According to a first aspect of the present invention, a
`modular component for use in conjunction with a protocol
`Stack of a voice over internet protocol terminal comprises a
`Security manager, a security Stack interface (SSA) for inter
`facing between said Security manager and a protocol man
`65
`ager of Said protocol Stack, a Security terminal interface
`(SST) for interfacing between said Security manager and an
`
`60
`
`2
`application layer, a security media interface (SSM) for
`interfacing between said Security manager and a media
`controller, and a Security manager application interface
`(SMA) for interfacing between said Security manager and a
`Security application (PGP) outside Said Stack.
`Further according to the first aspect of the invention, the
`Security manager comprises a State machine having an idle
`State and a wait for authorization State.
`Further Still according to the first aspect of the invention,
`a transition to Said wait authorization State from Said idle
`State occurs in response to an unauthorized invitation
`received and Signaled from and to an initiating remote
`device wherein a transition from Said wait authorization
`State to Said idle State occurs in response to an authorized
`invitation.
`According to a Second aspect of the invention, a Session
`initiation protocol (SIP) signaling Stack for a voice over
`intemet protocol (VoIP) terminal device, said Stack having
`an application interface and a media interface to a telephony
`application and having a protocol interface to a network
`layer, Said Stack comprises an SIP manager having Said
`application interface and a media controller having Said
`media interface to Said telephony application and Said pro
`tocol interface between said network layer and both said SIP
`manager and Said media controller, and a Security manager
`having a plurality of interfaces to Said SIP manager, Said
`telephony application, and to Said network layer.
`Further according to the Second aspect of the invention,
`the plurality of interfaces includes a Security Stack interface
`(SSA) between said SIP manager and said Security manager,
`a security terminal interface (SST) between said telephony
`application and Said Security manager, a Security media
`interface (SSM) between said Security manager and Said
`media controller, a Security manager application interface
`(SMA) between said Security manager and a Security appli
`cation (PGP) outside said stack.
`According to a third aspect of the invention, a method
`comprises the Steps of Sending an invite Signal from a
`Session initiation protocol (SIP) stack of a sending terminal
`to a remote user agent (UA), receiving an unauthorized
`signal (401. Unauthorized) at said SIP stack from said
`remote UA indicating authorization is required, providing an
`indication signal got 401 unauthorized) from Said SIP
`Stack to a Security manager module of Said Sending terminal
`indicative of receipt of Said unauthorized Signal, providing
`an authenticate Signal (send www authenticate) with
`required information and authorization header field from
`Said Security manager module to Said SIP Stack, calling
`encryption and authorization function requests from Said SIP
`Stack to Said Security manager, encrypting and authorizing
`Said required Information, and Sending an authorized invite
`signal from said SIP stack to said remote UA.
`According to a fourth aspect of the invention, a method
`comprises the Steps of receiving an invite Signal from a
`remote user agent (UA) at a Session initiation protocol (SIP)
`Stack of a receiving terminal, providing a Signal indicative of
`receipt of Said invite Signal from Said SIP Stack to a Security
`manager module of Said receiving terminal for checking
`Security parameters of Said invite Signal, providing an
`authenticate signal (send www authenticate) from Said
`Security manager to Said SIP Stack, Sending an unauthorized
`signal (401 unauthorized) from said SIP stack to said
`remote UA, receiving an authorized invite Signal from Said
`remote UA to Said SIP Stack, providing a request to authen
`ticate Said authorized invite signal to Said Security manager
`module, checking parameters of Said authorized invite Signal
`
`17
`
`

`

`3
`by Said Security manager module, and providing an authen
`tication Signal from Said Security manager module to Said
`SIP stack indicative of said step of checking.
`According to a fifth aspect of the invention, a telecom
`munications System comprises a Sending terminal for Send
`ing an invite signal from a session initiation protocol (SIP)
`Stack of a Sending terminal, and a receiving terminal respon
`Sive to Said invite Signal for providing a signal indicative of
`receipt of Said invite Signal from Said SIP Stack to a Security
`manager module of Said receiving terminal for checking
`Security parameters of Said invite Signal, wherein Said Secu
`rity manager provides an authenticate Signal to Said SIP
`Stack and Said SIP then sends an unauthorize Signal to Said
`Sending terminal in the presence of an unauthorized invite
`Signal from Said Sending terminal, wherein Said SIP Stack of
`Said Sending terminal is responsive to Said unauthorized
`Signal from Said receiving terminal indicating authorization
`is required, and wherein Said Sending terminal provides an
`indication Signal from Said SIP Stack of Said Sending termi
`nal to a Security manager module of Said Sending terminal
`indicative of receipt of Said unauthorize Signal, wherein Said
`Security manager provides an authenticate Signal with
`required information and authorization header field to Said
`SIP stack of said sending terminal, wherein said SIP stack of
`Said Sending terminal Sends an authorized invite signal to
`Said receiving terminal, wherein Said receiving terminal
`receives Said authorized invite signal from Said Sending
`terminal at Said SIP Stack of Said receiving terminal, wherein
`Said SIP Stack provides a request to authenticate Said autho
`rized invite Signal to Said Security manager module of Said
`receiving terminal, wherein Said Security manager checks
`parameters of Said authorized invite signal and provides an
`authentication signal to Said SIP Stack of Said receiving
`terminal indicative of Said Step of checking.
`35
`The Solution provides the required Security capabilities. A
`modular design is provided and only minor changes to the
`lower layer of the Stack are needed to connect the Security
`manager with the Stack. The interaction between the Stack
`and the Security module occurs by means of five signals and
`four interface functions. The major benefit of this kind of
`architecture is that the call control Stack is not changed and
`only valid calls proceed to the Stack, while all authentication
`and Security functions are done at the lower level.
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 shows the SIP protocol stack, according to the
`prior art.
`FIG. 2 shows SIP basic operation, according to the prior
`art.
`FIG.3 shows SIP proxy server operation, according to the
`prior art.
`FIG. 4 shows SIP redirect server operation, according to
`the prior art
`FIG. 5 shows an encryption process, according to the
`prior art.
`FIG. 6 shows data origin authentication with one-way
`hash function and a Secret key, according to the prior art.
`FIG. 7 shows SIP authentication, according to the prior
`art.
`FIG. 8 shows the current architecture of the target system,
`according to the prior art.
`FIG. 9 shows the current architecture of the SIP protocol
`Stack, according to the prior art.
`FIG. 10 shows secure SIP protocol stack architecture,
`according to the present invention.
`
`4
`FIG. 11 shows a signaling change in the protocol Stack,
`according to the present invention.
`FIG. 12 shows how FIGS. 12(a) and 12(b) fit together and
`show MSC for call initiation, according to the present
`invention.
`FIGS. 12(a) and 12(b) together show MSC for call
`initiation, according to the present invention.
`FIG. 13 shows how FIGS. 13(a) and 13(b) fit together and
`ShowS MSC for receiving a call, according to the present
`invention.
`FIGS. 14(a), 14(b) and 14(c) altogether show a state
`diagram for the Security manager, according to the present
`invention.
`
`BEST MODE FOR CARRYING OUT THE
`INVENTION
`
`I. Session Initiation Protocol (SIP)
`The Session Initiation Protocol (SIP) is a text-based
`client-server protocol, similar to HTTP and SMTP. SIP is an
`application-layer Signalling protocol that handles the asso
`ciation between intemet end Systems by creating, modifying
`and terminating multimedia Sessions. Members participating
`in a multimedia Session can communicate via multicast or
`via a mesh of unicast relations, or a combination of these.
`SIP is developed by IETF’s MMUSIC working group and
`the SIP working group is chartered to continue the devel
`opment.
`A. SIP Architecture
`(i) Terminals
`Terminals or user agents are client endpoints able to
`receive and place calls. The endpoints generate and receive
`bi-directional real-time information Streams. A terminal can
`either be a Software run in a personal computer or a
`dedicated hardware appliance. The terminal must Support
`Voice communications, whereas Video and data are optional.
`The SIP user agent has two basic functions.
`1. The User Agent Server (UAS) is a server application
`that contacts the user when a SIP request is received and that
`returns a response on behalf of the user.
`2. The User Agent Client (UAC) is a client application
`that initiates a SIP request.
`(ii) SIP Network Elements
`There are different types of Servers: proxy, redirect,
`location, registrar and UASS. Servers are mainly used to
`route and redirect calls. A SIP server can operate in either
`proxy or redirect mode, depending on how the next-hop
`Server is connected and if the user is not located on the
`contacted Server. A redirect Server informs the caller to
`contact another Server directly. A proxy server contacts one
`or more next-hop Servers itself and passes the call requests
`further.
`(iii) Proxy Server
`A proxy is an intermediate entity that acts as both a Server
`when receiving requests and a client for the purpose of
`making requests on behalf of the other clients. The requests
`are passed on, possibly after translation, to other Servers. A
`proxy can be a very Simple StateleSS packet forwarder or it
`can be a complex Statecapable proxy. A StateleSS proxy
`forgets all the information it has received once an outgoing
`request has been generated. StateleSS proxy is always based
`on UDP, whereas a State-capable proxy is usually based on
`TCP. Statecapable proxy acts as a virtual user agent and
`implements the Server State machine when receiving
`requests and the client State machine for generating outgoing
`requests. A proxy should implement loop detection by
`
`US 6,865,681 B2
`
`1O
`
`15
`
`25
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`18
`
`

`

`US 6,865,681 B2
`
`6
`BYE: terminates a connection between two users
`OPTIONS: signals information about capabilities
`All requests, except REGISTER, must be supported by the
`SIP proxy, redirect and user agent Servers as well as by
`clients. Support for the REGISTER request is optional.
`(ii) Response Messages
`A Server responses to the requests with a response mes
`sage. The syntax of the response code is similar to HTTP.
`The three digit codes are hierarchically organized, with the
`first digit representing the result class and the other two
`digits providing additional information. The first digit con
`trols the protocol operation and the other two gives useful
`but not critical information. SIP entities do not need to
`understand the meaning of all registered response codes, but
`they must be able to recognize the class of the response and
`treat any unrecognized response as being the X00 response
`code of the class. The following response codes are used in
`SIP.
`1XX: Informational-request received, call in progress,
`continuing to process the request (These responses are
`always followed by other responses indicating the final
`result.)
`2XX: Success-the action was Successfully received,
`understood, and accepted
`3XX: Redirection-further action needs to be taken in
`order to complete the request
`4XX: Client Error-the request contains bad Syntax or
`cannot be fulfilled at this server
`5XX: Server Error-the server failed to fulfil an apparently
`valid request
`6XX: Global Failure-the request cannot be fulfilled at any
`SCWC
`Responses are always Sent back to the entity that Sent the
`message to the Server, not to the originator of the request.
`The message is repeated regularly until the destination
`acknowledges with an ACK message. A positive response to
`a Setup message also contains a Session description, describ
`ing the Supported media types. Call identifiers are used to
`indicate messages belonging to the same conference.
`(iii) Header Fields
`Requests and responses include header fields to Specify
`parameterS Such as caller, called party, type and length of the
`message body. Currently there are 37 different header fields
`defined, but a SIP entity does not need to understand all of
`these header fields, although it is desirable. The header
`fields, which are not understood, can just be ignored.
`Header fields can be divided into four different groups as
`shown in Table 1 below:
`
`S
`always checking whether its own address is on the list of a
`Via header field in order to prevent loops.
`(ii)(b) Redirect Server
`A redirect server only informs the caller about the next
`hop, and the caller sends a new request to the Suggested
`receiver directly. After receiving a SIP request, a redirect
`Server maps the address into Zero or more new addresses and
`returns these addresses to the client. Now the client can
`contact the next server directly. Unlike a proxy server, a
`redirect server does not initiate its own SIP request and
`unlike an user agent it does not accept calls.
`(ii)(c) Location Server
`A SIP System may also include a location Server, that
`keeps a database of the locations of the users. A location
`Server is used by a redirect or proxy Server to obtain
`information about the called party's possible location. The
`location server is typically co-located with a SIP proxy but
`it may also be co-located with another SIP server.
`(ii)(d) Registrar
`A registrar is a server that accepts REGISTER requests,
`by which users can register their location with SIP servers.
`A registrar is typically co-located with a proxy or redirect
`Server and may offer location Services.
`B. Protocols Involved in SIP
`Basically SIP is rather independent of the environment
`and can be used in conjunction with Several transfer proto
`cols. It does not require any specific transfer protocol but it
`is recommended that servers should support both UDP and
`TCP. The Session Description Protocol (SDP) is used by SIP
`for description of the capabilities and media types Supported
`by the terminals. Text based SDP messages, which are sent
`in SIP message bodies, lists the features that must be
`Supported by the terminals. The real time data is transferred
`by RTP in conjunction with RTCP. SIP protocol stack in an
`intemet environment is described in FIG. 1.
`C. SIP Addressing
`For addressing SIP uses an email-like identifier (SIP
`URL) in the form sip: user(a)host, where the user part is a
`user name or phone number and the host part is either
`domain or a numeric network address. In many cases the
`email-like name may be the same as user's email address
`and can be easily mapped. The address may also be used for
`group of individuals So that it specifies the first available
`person from the group or the whole group.
`D. SIP Message Structure
`SIP is a client-server protocol, message is either a request
`from a client to a Server, or a response from a server to a
`client. Requests and responses are in textual form and
`include different header fields to describe the details of the
`communication. SIP reuses many of the header fields used in
`HTTP (Hypertext Transfer Protocol), such as entity and
`authentication headers. Message begins with a Start-line
`followed by one or more header fields. After the header
`fields the message may contain body which is separated
`from the header fields by an empty line.
`(i) Request Messages
`As in HTTP, the client requests invoke methods on the
`Server. The request message consist of a Start-line Specifying
`the method and the protocol, a number of header fields
`Specifying the call properties and Service information, and
`an optional message body. The following methods are used
`in SIP
`REGISTER: conveys location information to a SIP server
`INVITE: invites user to a session or a conference
`ACK: is used in reliable message exchanges for acknowl
`edgement
`CANCEL: cancels a pending request
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`General
`header
`fields
`
`Accept
`
`Accept-
`Encoding
`Accept-
`Language
`Call-ID
`Contact
`Cseq
`Date
`
`65
`
`Encryption
`Expires
`
`TABLE 1.
`
`Entity
`header
`fields
`
`Content-
`Encoding
`Content-
`Length
`Content-
`Type
`
`Response
`header
`fields
`
`Request
`header
`fields
`
`Allow
`
`Authorization
`
`Contact
`
`Proxy-
`Authenticate
`Retry-After Hide
`
`Max-Forwards
`Server
`Unsupported Organization
`Warning
`Priority
`WWW-
`Proxy
`Authenticate Authorization
`Proxy-Require
`Route
`
`19
`
`

`

`US 6,865,681 B2
`
`8
`message contains SDP Session description, which consists of
`the one letter codes at the end of the message. The Session
`description tells that tenninal wants to use RTP in port 5004
`with formats 0, 3 or 5.
`
`TABLE 1-continued
`
`Entity
`header
`fields
`
`Response
`header
`fields
`
`Request
`header
`fields
`
`Require
`Response-Key
`Subject
`User-Agent
`
`General
`header
`fields
`
`From
`Record-Route
`Timestamp
`To
`Via
`
`The first group consists of general header fields that are
`used in both requests and responses. Entity header fields
`contain information about the message body or, if no body
`is present, the resources identified by the request. Request
`header fields again act as request modifiers and allow the
`client to pass additional information to the server. The fourth
`group is response header fields, which allow the Server to
`pass additional information about the response that cannot
`be placed in the response Status-line.
`E. Session Description Protocol (SDP): RFC 2327
`When the users are invited to multimedia conferences,
`SIP states how communication between the caller and the
`called party, addressing and user location resolving is done.
`Furthermore, there is a need to describe the context of a
`multimedia Session. The Sessions are typically described
`using the SDP, although other protocols can also be used.
`The Session description is contained in the message body.
`The SDP conveys information about media streams in
`multimedia Sessions giving the recipients of the Session
`description enough information to participate in the Session.
`An SDP session description consists of a number of text
`lines containing type-value pairs. The type is always exactly
`one case-significant character and the value is a structured
`text String whose format depends on type. Some lines in
`each description are required and Some are optional but all
`must appear in exactly the order given in Table 2 below.
`Optional items are marked with a *.
`
`TABLE 2
`
`Session description
`
`Type Description
`
`v Protocol version
`
`o Owner/creator and session
`identifier
`Session name
`Sesson information
`
`s
`i
`
`u URI of description
`
`Email address
`e
`p* Phone number
`
`c
`
`Connection information - not
`required if included in all media
`b Bandwidth information
`z* Time Zone adjustments
`
`k* Encryption key
`a
`Zero or more session
`
`attribute lines
`
`Time Description
`
`t Time the session is
`activated
`r* Zero or more repeat times
`Media description
`
`m Media name and transport
`address
`i Media title
`c Connection information -
`optional if included at
`session level
`b Bandwidth information
`
`k* Encryption key
`a Zero or more media
`attributes
`
`F. Example SIP Message
`An example INVITE-request message from user
`bob(Ofirm.com to pete(a)company.com is represented here.
`The first line is the request line beginning with method token
`followed by request-URI and protocol version. After the first
`row other headers follow. Content-type informs that the
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`INVITE sip:peted company.com SIP/2.0
`Via: SIP/2.0/UDP user.firm.com
`From: Bob <sip:bobGfirm.com.>
`To: Pete <sip:peteCocompany.com.>
`Call-ID: 1234567890G user.firm.com
`Cseq: 1 INVITE
`Subject: Document
`Content-Type: application/sdp
`Content-Length: 109
`w-O
`O=Bob S3655765 2353687637 INIP4 123.56.43.23
`S=call
`c=INIP4 user.firm.com
`m=audio 5004 RTP/AVP O 35
`
`The request is responded with a response message, which is
`very similar to the request message. The first row contains
`response code (200=Success). The response SDP tells that
`formats 0 and 3 are accepted.
`
`SIP/2.O 200 OK
`Via: SIP/2.0/UDP sip.company.com
`Via: SIP/2.0/UDP user.firm.com
`From: Pete <sip:peteocompany.com.>
`To: <sip:bobGfirm.com.>
`Call-ID: 1234567890G user.firm.com
`Cseq: 1 INVITE
`Content-Type: application/sdp
`Content-Length: 103
`w-O
`O-Peter 4858949 4858949 INIP4 198.514.43
`S=OK
`c=IN IP4 user.company.com
`m=audio 5004 RTP/AVP O 3
`
`G. SIP Operation
`(i) Basic Operation
`The basic operation (FIG. 2) of SIP is very simple. First
`endpoint 1 invites endpoint 2 with INVITE message con
`taining Session description. The called party, endpoint 2
`agrees to communicate and responds 200 OK with accepted
`call parameters. After receiving acceptation, endpoint 1
`Sends ACK message to confirm that it has received the
`response.
`Normally transfer includes also other network compo
`nents and SIP operates either in proxy- or in redirect Server
`mode. Both of these operation modes are described below.
`In the proxy server operation mode (FIG. 3) an INVITE
`request is generated and Sent to the proxy server. The Server
`accepts the invitation and contacts its location Server for a
`more precise location. The location Server returns the loca
`tion of the endpoint 2. The proxy sends an INVITE request
`to the address given by the location Server where the pr