USOO8539552B1
`
`(12) United States Patent
`(10) Patent No.:
`US 8,539,552 B1
`
`Grabelsky et al.
`(45) Date of Patent:
`Sep. 17, 2013
`
`(54) SYSTEM AND METHOD FOR NETWORK
`BASED POLICY ENFORCEMENT OF
`INTELLIGENT-CLIENT FEATURES
`
`(75)
`
`Inventors: David Grabelsky, Skokie, IL (US);
`-
`-
`'
`.
`$11.10? Tfipathi’ Lafizuglm’ tHiLwSé’ .
`1° “6
`”ne‘er:
`e ores ,
`(U ),
`Guanglu Wang, Buffalo Grove, IL (US)
`
`(73) Assignee: Hewlett-Packard Development
`Company, L.P., Houston, TX (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 15403) by 1045 days.
`
`2001/0024436 A1 *
`2002/0075844 A1*
`2002/0116643 A1*
`2002/0124112 A1 *
`2003/0081607 A1*
`2003/0093563 A1*
`2003/0177363 A1*
`2004/0029564 A1 *
`2004/0057188 A1 *
`2004/0193906 A1 *
`
`........ 370/352
`9/2001 Barraclough et a1.
`370/351
`6/2002 Hagen .................
`
`713/201
`8/2002 Raanan et a1.
`709/246
`9/2002 Tso .................
`370/392
`5/2003 Kavanagh
`
`709/245
`5/2003 Young et a1.
`713/176
`9/2003 Yokota et a1.
`455/411
`2/2004 Hodge ............
`
`361/119
`3/2004 Phillips et a1.
`...................... 713/200
`9/2004 Dar et a1.
`
`OTHER PUBLICATIONS
`Request for Comments: 3303, “Middlebox communication architec-
`ture and framework,” MIDCOM Architecture and Framework, p.
`1-34 Aug. 2002.
`U.S.App1.No. 10/243,642, Architecture and Method for Controlling
`Features and Services in Packet-BasedNetworks, p. 1-48, Sep. 2002.
`
`(21) Appl. No.: 10/671,375
`.
`.
`,
`(22) Filed'
`Sep 25 2003
`
`* Cited by examiner
`
`Primary Examiner 7 Gilberto Barron, Jr.
`Assistant Examiner 7 Roderick Tolentino
`
`(51)
`
`(2006.01)
`
`Int. Cl.
`H04L 29/06
`(52) US. Cl.
`USPC .................................. 726/4; 726/21; 709/225
`(58) Field of Classification Search
`USPC ................ 713/ 166; 455/432.3, 433; 726/26;
`379/201 .01; 370/338, 332
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`9/ 1998 Pereira ............................ 726/35
`5,809,230 A *
`
`. 713/175
`6,446,206 Bl *
`9/2002 Feldbaum .....
`
`6,625,141 131*
`~~~~~~~~~~~~~~ 370/352
`9/2003 Glitho et 31'
`6,667,971 B1 * 12/2003 Modarressi et a1.
`.
`..... 370/352
`............... 709/230
`6,678,735 B1 *
`“2004 0mm et a1.
`
`..... 709/229
`6,785,728 B1 *
`8/2004 Schneider et a1.
`
`7,136,373 B2 * 11/2006 Ma ......................... 370/352
`4/2007 Rowe ............................ 725/144
`7,207,057 B1 *
`
`ABSTRACT
`(57)
`A system and method for network based policy enforcement
`of intelligent-client features is provided. An operator of an IP
`telephony and/or IP multimedia network may enforce autho-
`rization or privileges of intelligent end-user clients to utilize
`or invoke services in the network. A network policy enforce-
`ment point is maintained in the network by elements that are
`under control of the network operator. The network policy
`enforcement point controls access to, and invocation of, fea-
`tures and services that may otherwise be delivered to sub-
`scribers without the knowledge or authorization of the net-
`work. The network policy enforcement point
`receives
`messages, associates the message with a known service,
`makes a determination as to whether a beneficiary of the
`.
`.
`.
`.
`.
`serv1ce 1s author1zed to 1nvoke the serv1ce, and then filters the
`messages based on the determlnatlen
`
`25 Claims, 7 Drawing Sheets
`
`100
`
`N
`
`
`
`
`
`112
`116
`
`
`.‘4
`
`
`
`Authentication 81
`all“
`
`T
`Authorization \
`fl!
`.
`Signaling &
`Call Control
`Net::rr\:cl;assed
`103
`110
`
`
`
`.
`
`Core Packet
`
`a Network a
`
`Border Element/ALG
`
`Border Element/ALG
`
`104
`
`
`104i:
`
`
`
`’
`lntelllgeii: Cllent
`
`1063
`
`106!)
`
`
`
`
`
`W —
`
`Local Packet
`Network
`1015
`
`105.:
`Intelligent Client
`
`106d 5
`Intelligent Client E 106e
`Intelligent Client
`
`Apple Inc.
`EX. 1018 - Page 1
`
`Apple Inc.
`Ex. 1018 - Page 1
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 1 of 7
`
`US 8,539,552 B1
`
`ExommEco...
`
`x3352
`
`
`
`
`
`
`
`
`amxomn..80...
`
`x3352
`
`«.3
`
`
`
`22.0“59:2...hmmDmHE
`
`fi
`
`.flE2.EwQ2:$3mmmo___“5:359:95
`
`Apple Inc.
`EX. 1018 - Page 2
`
`
`
`923555.22892:852."..oEom
`
`
`
`
`
`Imm
`
`
`
`inx5332_II3.3
`
`mos.
`
`
`
`
`
`
`
`6039:3szwm:=m:m_m//cozmutofii
`mwo_>._ww35:00=m0
`
`
`.m:o_umo_uco£:<
`
`oE‘
`
`Kiowa.200we
`
`
`
`{oer
`
`Apple Inc.
`Ex. 1018 - Page 2
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 2 of 7
`
`US 8,539,552 B1
`
`
`
`ammunihozswz«an
`
`$03.35I.
`
`€03waE200
`
`mrN0539mm
`
`=m>>w.__u=._.<z
`
`
`l
`
`
`
`.m:o_amo_uco£:<
`
`:o=aN_._o£:<
`
`
`
`
`
`
`
`
`
`2959mm
`
`=m>>w.__u=._.<z
`
`22:.EmW.
`95:;Em
`
`NHEDGE
`
`
`
`
`
`
`
`
`€03quE
`
`2.anEm
`
`ococmEm
`
`Apple Inc.
`Ex. 1018 - Page 3
`
`Apple Inc.
`Ex. 1018 - Page 3
`
`
`
`
`
`

`

`US. Patent
`
`Sep. 17, 2013
`
`Sheet 3 of7
`
`US 8,539,552 B1
`
`START
`
`r 300
`
`Associating signaling and/or call control message with a
`
`known service or feature
`
`302
`
`304
`
`Determining whether a sender and/or intended recipient
`of the message is authorized to use and/or invoke the
`identified service or feature
`
`
`
`
`Filtering each signaling and/or call control message
`according to whether or not the identified service or
`
`
`
`feature is authorized for the sender and/or intended
`
`305
`
`
`
`
`recipient of the message
`
`
`
`Communicating with one or more network entities to
`
`303
`
`ensure compliance with network resource usage
`
`m
`
`FIGURE 3
`
`Apple Inc.
`EX. 1018 - Page 4
`
`Apple Inc.
`Ex. 1018 - Page 4
`
`

`

`U.S. Patent
`
`Sep.17,2013
`
`Sheet40f7
`
`US 8,539,552 B1
`
`§3332.”.
`
`%83.35
`
`5:0;
`
`
`
` a33...".—Emeohoh—cm
`
`{02:02
`
`ov«”5955Ban.
`
`E5595
`
`%0&3
`
`VWMDGE
`
`Apple Inc.
`Ex. 1018 - Page 5
`
`Apple Inc.
`Ex. 1018 - Page 5
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 5 of 7
`
`US 8,539,552 B1
`
`n=w.350
`
`
`
`:ozantofizd..wtww=§>2E"=m§2E"Emaécma5:82:05:36:.Em$35.5"ofizéém_
`
`m5.2n«'8a..298n22.0
`
`8mx5352n:200
`
`
` _m:ozflamacou._.<2.323:230:0U
`559.3%.mwmmfluuan:.30..o.320
`
`
`
`
`
`
`
`HEOQUCM/EwEwohoEw>o=om5:23:50.804
`
`
`
`
`
`
`
`
`
` €262m..m.33:5.Sago
`
`
`
`
`
`.olrlm.x3502n:3:30550.5._~oo._.550.200
`
`mHEDGE
`
`Apple Inc.
`Ex. 1018 - Page 6
`
`Apple Inc.
`Ex. 1018 - Page 6
`
`
`
`
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 6 of 7
`
`US 8,539,552 B1
`
`
`
`
`
`u:_on_u:mEmeohoEm>o=om52839200.80...
`
`
`
`
`
`9:26
`
`5.3>55Sic
`
`ax3252n:.3:th$50.0._moo._350.950
`
`mHEDGE
`
`Apple Inc.
`EX. 1018 - Page 7
`
`n=m550
`
`
`:o=~N_.o£:<
`
`.wEmma=o=S=E£=<as:n__m
`
`.3£205”.
`
`whm>><ul_m
`
`.332“.
`
`5.2Ba
`
`_lnInso
`_Son“:26"=m>>o.__u_"Emmaficm
`
`_ w
`
`._
`
`__
`hm>><un=m
`
`cmx3332n=200
`
`
`
`
`
`AxhoEo:9.3Eh<zvL3:03233n:.30..
`
`Apple Inc.
`Ex. 1018 - Page 7
`
`
`
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 7 of 7
`
`US 8,539,552 B1
`
`
`
`maEEmEmEmSoEm.3:0;
`
`
`
`
`
`,:ozflamccou._.<z.323:25..:0
`
`
`
`
`
`whx3282n:28gfoEozn:.83
`
`
`
`r005
`
`
`
`.mEvcoawu.3323“n:.30.._o.320
`
`
`
`
`
`
`
`:osmntofisd..mew=m>>2_u_"=M>>2E“.wmzécmw8:855:54.98:.Emo..m;<i_m"2m;<d_w_IIIIIIIIL
`
`.3.355."._.<z"«fl"365n22.0
`
`ax8502n:3:30550.o__moo._550.200
`
`5HEDGE
`
`Em.26
`
`.anucm
`
`..m.mv
`
`€26
`
`
`
`53959200.30..
`
`8:3
`
`Apple Inc.
`Ex. 1018 - Page 8
`
`Apple Inc.
`Ex. 1018 - Page 8
`
`
`
`
`
`
`
`

`

`US 8,539,552 B1
`
`1
`SYSTEM AND METHOD FOR NETWORK
`BASED POLICY ENFORCEMENT OF
`INTELLIGENT-CLIENT FEATURES
`
`FIELD OF INVENTION
`
`The present invention relates to policy enforcement of
`network services and, more particularly, to a system and
`method for network based policy enforcement of intelligent-
`client features.
`
`BACKGROUND
`
`The emergence of Internet Protocol (IP) telephony and IP
`multimedia networks poses challenges to carriers and service
`providers, however, it also presents new and expanded busi-
`ness opportunities. The increasing use of IP telephony has
`spurred development and introduction of numerous tele-
`phony services. The use of IP telephony protocols as an
`interface may assure that a “customer” and a “server” can rely
`on a common and widely used method for exchanging infor-
`mation. The protocols developed for IP-based services, fea-
`tures, and media transport enable migration of signaling and
`call-control
`functionality to intelligent end-user clients.
`Examples of such protocols include H.323 and the Session
`Initiation Protocol (SIP). To the extent that telephony services
`and features can be implemented in intelligent clients, the
`carriers and service provider network’s responsibilities
`include little more than providing data pipes.
`In practice, however, many next-generation services still
`depend upon network-based servers and support, so network
`providers are probably in no danger of loosing their ability to
`sell services. But the trend toward intelligent, IP-based clients
`is a new dimension in the space of creation and delivery of
`telephony and media services. At best, carriers, service pro-
`viders, and device manufacturers may have to work together
`to ensure interoperability. At worst, carriers and service pro-
`viders may need to deal with unauthorized delivery of ser-
`vices by intelligent clients in their networks. Either way,
`maintaining relevance as providers of services, and not just
`transport of the services, is no longer a given for network
`providers in a world shared with intelligent clients.
`Therefore, if carriers and service providers are to maintain
`their ability to generate revenue for services offered or sup-
`ported in their networks, then the service providers’ ability to
`enforce the authorization of service usage is important. This
`is particularly important in next-generation IP telephony and
`IP multimedia networks, where many basic and advanced
`services may be signaled, controlled, and/or delivered by
`intelligent end-user clients that are not owned or controlled by
`the network providers, thereby enabling potential bypassing
`by the end user of service agreements or other subscription
`accounting mechanisms.
`
`SUMMARY
`
`In an exemplary embodiment, a method for controlling
`services in packet-based networks is provided. The method
`includes receiving signaling messages within a communica-
`tion path between a sender and a recipient device. The sig-
`naling messages include an indication of a type of service
`which the messages are intended to invoke. The method fur-
`ther includes making a determination ofwhether the sender or
`the recipient of the messages is authorized to invoke the type
`of service, and filtering the signaling messages based on the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`
`determination so as to pass to the intended recipient device
`signaling messages having an indication of services that are
`authorized.
`
`In another respect, the exemplary method for controlling
`services in packet-based networks includes receiving a mes-
`sage, which is configured according to a protocol, and asso-
`ciating the message with a known service that is defined
`within the protocol. This method includes requesting a user
`profile of a user associated with the message that specifies
`which services the user is authorized to use. This method also
`
`includes determining from the user profile whether the user is
`authorized to invoke the known service, and filtering the
`message based on whether the user is authorized to invoke the
`known service.
`
`In still another respect, the exemplary embodiment may
`take the form of a system that includes a border element and
`a proxy server. The border element is in a communications
`path of session initiation protocol (SIP) signaling messages
`between end devices, and may filter the SIP signaling mes-
`sages based on authorized services of the end devices. The
`SIP signaling messages include an indication of services. The
`proxy server may receive a request from the border element
`for a user profile of at least one of the end devices, and in
`response, send the user profile to the at least one of the end
`devices. The user profile specifies which services the at least
`one end device is authorized to use.
`
`These as well as other features and advantages will become
`apparent to those of ordinary skill in the art by reading the
`following detailed description, with appropriate reference to
`the accompanying drawings.
`
`BRIEF DESCRIPTION OF FIGURES
`
`invention are
`Exemplary embodiments of the present
`described with reference to the following drawings, in which:
`FIG. 1 is a block diagram illustrating one embodiment of a
`network architecture for support of packet-based telephony
`and multimedia sessions and services according to the present
`invention;
`FIG. 2 is a block diagram illustrating another embodiment
`of a network architecture for support of packet-based tele-
`phony and multimedia sessions and services according to the
`present invention;
`FIG. 3 is a flowchart depicting one embodiment of a
`method of network-based policy enforcement of intelligent
`client features;
`FIG. 4 illustrates one embodiment of a network policy
`enforcement entity that may carry out the method of FIG. 3;
`FIG. 5 illustrates one embodiment of a SIP-aware firewall
`
`functioning as the network policy enforcement point;
`FIG. 6 illustrates one embodiment of a SIP-aware NAT and
`
`a firewall functioning as the network policy enforcement
`point; and
`FIG. 7 illustrates one embodiment of a SIP-aware firewall
`
`and a SIP Proxy server functioning as the network policy
`enforcement point.
`
`DETAILED DESCRIPTION OF EXEMPLARY
`EMBODIMENTS
`
`In packet-based networks, intelligent end-user clients with
`little or no support and/or knowledge of the network can
`deliver many features and services. For networks to retain
`control over the features and services used by subscribers that
`use intelligent end-user clients, the networks need to be able
`to recognize signaling and call control messages and transac-
`tions that implement these features and services within the
`
`Apple Inc.
`Ex. 1018 - Page 9
`
`Apple Inc.
`Ex. 1018 - Page 9
`
`

`

`US 8,539,552 B1
`
`3
`network. This is particularly important in next-generation IP
`telephony and IP multimedia networks where many basic and
`advanced services may be signaled, controlled, and/or deliv-
`ered by intelligent end-user clients which are not owned or
`controlled by the network or service providers,
`thereby
`enabling the potential bypassing by the end user of service
`agreements or other subscription accounting mechanisms.
`One approach to policing network service usage is to
`extend signaling and control protocols, such as the Session
`Initiation Protocol (SIP), to support informing the intelligent
`client as to which services are authorized. This approach is
`described in US. patent application Ser. No. 10/243,642,
`filed on Sep. 10, 2002, and entitled “Architecture and Method
`for Controlling Features and Services in Packet-Based Net-
`works,” which is entirely incorporated by reference herein as
`if fully set forth in this description. This approach relies on the
`ability of the client to support required protocol extensions,
`and to function as the policy enforcement point on behalf of
`the network.
`
`invention
`the present
`In the exemplary embodiment,
`describes a system and method for using network-based
`policy enforcement to control access to, and invocation of,
`features and services which may otherwise be delivered to
`subscribers without the knowledge or authorization of the
`network. An operator ofan IP telephony and/or IP multimedia
`network may enforce authorization or privileges of intelligent
`end-user clients to utilize or invoke services in the network,
`even when the capabilities for the requisite signaling and call
`control of those services may reside in the end-user clients
`themselves.
`
`In the exemplary embodiment, a policy enforcement point
`is maintained in the network by elements that are under con-
`trol of the network operator. This approach lessens and/or
`eliminates a need for the network operator to police the selec-
`tion of client devices, and at the same time, allows end users
`to install nearly any suitable device of their choosing.
`Network Architecture
`
`Referring now to the figures, FIG. 1 is a block diagram
`illustrating one embodiment of a network 100. It should be
`understood that this and other arrangements described herein
`are set forth for purposes of example only, and other arrange-
`ments and elements can be used instead and some elements
`
`may be omitted altogether. Further, many of the elements
`described herein are functional entities that may be imple-
`mented as hardware, firmware or software, and as discrete
`components or in conjunction with other components, in any
`suitable combination and location.
`
`45
`
`The network 100 includes functionality of a packet net-
`work architecture for support of packet-based telephony and
`multimedia sessions and services. The network 100 includes
`
`50
`
`a core packet network 102, and two local packet networks 104
`and 106, as well as intelligent end-user clients 104a-d and
`106a-e associated with the local packet networks 104 and
`106. Access to the core packet network 102 is available
`through border elements 108 and 110, such as a firewall or
`application layer gateway (ALG) device. Maintaining the
`border elements 108 and 110 within the core packet network
`102 may protect the core packet network 102 from errant
`behavior of extra-network elements, whether malicious or
`inadvertent. Note that local packet networks 104 and 106 may
`likewise employ border elements for security purposes.
`The core packet network 102 includes a signaling and call
`control server 112, an authentication and authorization sever
`114, and a network-based services server 116. The signaling
`and call control server 112 intercepts call set-up messages
`sent between the end-user clients, e. g., intelligent client 104c,
`and the core packet network 102 and checks the authentica-
`
`55
`
`60
`
`65
`
`4
`tion and authorization server 114 to determine what services
`
`the client may invoke. In turn, the signaling and call control
`server 112 may contact the network-based services server 116
`to invoke any services requested by the client, if the client is
`authorized to invoke the service.
`
`The local packet networks 104 and 106 may be local area
`networks (LANs). The LAN provides local connectivity for
`end-user clients, while the core packet network 102 provides
`access to global packet telephony services, as well as possibly
`to a public packet data network. The core packet network 102
`connects the local packet networks 104 and 106 to other local
`networks, as well as to the public switched telephone network
`(PSTN) via media gateways, for example.
`The local packet networks 104 and 106 may be maintained
`within private or restricted address spaces. That is, addresses
`of devices within or residing within a given local packet
`network may not be visible or valid to entities in the core
`packet network 102, or in other local networks. Rather, a
`mapping of addresses is used across the boundaries between
`the core packet network 102 and the local packet networks
`104 and 106. In this case, the border elements 108 and 110 in
`the core packet network 102 provide the mapping function-
`ality, translating between addresses on the core packet net-
`work 102 side and the local packet network side. In an IP
`network, for example, this could be supported with Network
`Address Translation (NAT). This may also be supported with
`Realm Specific Internet Protocol (as described in RFC 3104-
`3105). Alternatively, this address-mapping function may be
`accomplished on the local network side, but the core packet
`network 102 may still provide a subset of core network
`addresses that may be used in the mapping, i.e., access to the
`core packet network 102 first passes through some sort of
`core-network border element. Isolating the address space of
`the local packet networks 104 and 106 from the core packet
`network 102 introduces a stronger degree of control over
`access to services and features in the core packet network 102,
`because clients’ true addresses are hidden from entities out-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`side the local packet networks 104 and 106, which prevents
`surreptitious communications across the boundary between
`local and core networks.
`
`40
`
`If address mapping is used at the border between the core
`packet network 102 and the local packet networks 104 and
`106, then end-user devices can access services in the core
`packet network 102 with explicit awareness of some element
`or elements within the core packet network 102.
`FIG. 2 illustrates a specific example of a network 200,
`similar to that illustrated in FIG. 1, in which the packet net-
`works are IP networks. For this example, the SIP signaling
`and call control protocol is implemented. However, other
`signaling protocols, such as H-323, Media Gateway Control
`Protocol (MGCP), Media Gateway Control (MEGACO), and
`other standard or proprietary techniques may alternatively be
`used. A brief explanation of SIP is given below.
`SIP is described in Handley, et al., “SIP: Session Initiation
`Protocol,” IETF RFC 2543, March 1999, which is entirely
`incorporated by reference herein, as if fully set forth in this
`description. SIP is also described in Rosenberg et al., “SIP:
`Session Initiation Protocol,” IETF RFC 3261, June 2002, the
`contents of which are entirely incorporated herein by refer-
`ence, as if fully set forth in this description. SIP describes how
`to set up Internet telephone calls, videoconferences, and other
`multimedia connections. SIP can establish two-party sessions
`(ordinary telephone calls), multiparty sessions (where every-
`one can hear and speak), and multicast sessions (one sender,
`many receivers). The sessions may contain audio, video, or
`data. SIP handles call setup, call management, and call ter-
`mination. Other protocols, such as real time protocol (RTP)
`
`Apple Inc.
`EX.1018- Page 10
`
`Apple Inc.
`Ex. 1018 - Page 10
`
`

`

`US 8,539,552 B1
`
`5
`are used for data transport. SIP is an application layer proto-
`col and can run over the user datagram protocol (UDP) or the
`transport control protocol (TCP), for example.
`SIP supports a variety of services, including locating the
`callee, determining the callee’ s capabilities, and handling the
`mechanics of call setup and termination, for example. SIP
`defines telephone numbers as uniform resource locators
`(URLs), so that Web pages can contain them, allowing a click
`on a link to initiate a telephone call (similar to the mailto
`function that allows a click on a link to initiate a program to
`send
`an
`e-mail
`message).
`For
`example,
`John_Doe@3Com.com may represent a user named John at
`the host specified by the domain name system (DNS) of
`3Com. SIP URLs may also contain other addresses or actual
`telephone numbers.
`The SIP protocol is a text-based protocol in which one
`party sends a message in American standard code for infor-
`mation interchange (ASCII) text consisting ofa method name
`on the first line, followed by additional lines containing head-
`ers for passing parameters. Many of the headers are taken
`from multipurpose Internet mail extensions (MIME) to allow
`SIP to interwork with existing Internet applications.
`As an example, consider the following exemplary text
`encoded message below in Table 1.
`
`TABLE 1
`
`INVITE sip:user@biloxi.com SIP/2.0
`Via: SLP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
`Max-Forwards: 70
`To: User <sip:user@biloxi.com>
`From: Sender <sip:sender@atlanta.com>;tag=1928301774
`Call-ID: a84b4c76e66710@pc33.atlanta.com
`CSeq: 314159 INVITE
`Contact: <sip :sender@pc33 .atlanta.com>
`Content-Type: application/sdp
`Content-Length: 142
`
`This text-encoded message is a SIP INVITE message. The
`first line of this text-encoded message contains the method
`name (e.g., INVITE). The lines that follow are a list of header
`fields. For example, the fields Via (describing the address at
`which the user is expecting to receive responses), To (contains
`a display name or SIP request-URI towards which the request
`was originally directed), From (contains a display name and
`a SIP request-URI that indicate the originator of the request),
`Call-ID (contains a globally unique identifier for this call),
`CSeq (a traditional sequence number), and Contact (contains
`a SIP request-URI that represents a direct route to contact the
`sender) are header fields. In addition, the From header also
`has a tag parameter containing a random string (e.g.,
`1928301774) that is used for identification purposes.
`Other example methods are provided below in Table 2.
`
`TABLE 2
`
`METHOD
`
`DESCRIPTION
`
`INVITE
`ACK
`BYE
`OPTIONS
`CANCEL
`REGISTER
`
`NOTIFY
`REFER
`
`Request initiation of a session
`Confirm that a session has been initiated
`Request termination of a session
`Query a host about its capabilities
`Cancel a pending request
`Inform a redirection server about the
`user’s current location
`Indicates the status of a request
`Requests that the party sending the
`REFER be notified ofthe outcome ofthe
`referenced request
`
`6
`To establish a call session, a caller sends an INVITE mes-
`sage to a callee by way of a proxy server. The transport
`protocol for the transmission may be TCP or UDP, for
`example. In both cases, the headers on the second and subse-
`quent lines of INVITE message describe the structure of the
`message body, which contains the caller’s capabilities, media
`types, and formats. The INVITE message also contains a user
`identifier to identify the callee, a caller user identifier to
`identify the caller, and a session description that informs the
`called party what type of media the caller can accept and
`where the caller wishes the media data to be sent. User iden-
`
`tifiers in SIP requests are known as SIP addresses. SIP
`addresses are referred to as SIP Universal Resource Indica-
`
`10
`
`15
`
`(SIP request-URIs), which are of the form sip:
`tors
`user@host.domain. Other addressing conventions may also
`be used.
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`The proxy server will read the INVITE message and may
`use a location service locally or remotely located to itself to
`determine the location of the callee, as identified in the
`INVITE message. The proxy server determines the location
`ofthe callee by matching the SIP request-URI in the INVITE
`message to one within a location database, which may be
`within another proxy server. The INVITE request is then
`forwarded to the callee. Upon receiving the INVITE request,
`the callee may transmit a response message.
`The response message may be a reply code. A reply code
`may be a three-digit number with a classification as defined
`below in Table 3.
`
`TABLE 3
`
`CODE
`
`MEANING
`
`EXAMPLES
`
`1xx
`
`2xx
`3xx
`4xx
`5xx
`
`Information
`
`Success
`Redirection
`Client Error
`Server Error
`
`100 = server agrees to handle
`client’s request
`200 = request succeeded
`301 = page moved
`403 = forbidden page
`500 = internal server error
`
`the callee
`For example, if the callee accepts the call,
`responds with a 200 OK message. Following the reply code
`line, the callee also may supply information about the callee’ s
`capabilities, media types, and formats.
`Referring back to FIG. 2, the network 200 includes a core
`IP network 202, and local IP networks 204 and 206. In this
`case, end-user clients are SIP user agents, such as SIP user
`agent 204a-b and 20611-19, and SIP phones, such as SIP phone
`204c-d and 2060-6. The core IP network 202 includes a SIP
`
`50
`
`Proxy server 208, an authentication/authorization server 210,
`a directory server 212, and a network-based services server
`214. Border elements in the core IP network 202 are NAT
`
`55
`
`60
`
`65
`
`firewalls 216 and 218, which incorporate functionality spe-
`cific to SIP. Such devices are commonly referred to as SIP-
`aware firewalls, as illustrated. The NAT firewalls 216 and 218
`make it possible, for example, for a SIP client with only a
`local address within the local area network to initiate and
`
`receive SIP-based calls to and from SIP endpoints in the core
`IP network 202, or other local networks connected (directly
`or indirectly) to the core IP network 202.
`In order for a SIP phone, e.g., 204C, to establish connec-
`tivity beyond its local IP network 204, its user registers with
`the SIP proxy server 208 in the core IP network 202. The
`registration process will typically include some sort of veri-
`fication that authenticates the user and authorizes use of a set
`
`of services. This authentication usually involves communica-
`tions between the SIP proxy server 208 and the authentication
`and authorization server 210 via an additional protocol. For
`
`Apple Inc.
`EX.1018- Page 11
`
`Apple Inc.
`Ex. 1018 - Page 11
`
`

`

`US 8,539,552 B1
`
`7
`example, Remote Authentication Dial In User Service (RA-
`DIUS) might be used for this purpose. Assuming the user is
`successfully authenticated, authorization for use of services
`could be determined according to a user profile stored in the
`authentication and authorization server 210. The user profile
`might list services and features to which the user has sub-
`scribed, e.g., basic calls, call waiting, call forwarding, etc.
`Once registration is complete, the user may invoke services
`within the core IP network 202. Note that the user could be a
`
`specific person, group, or generic identity (e.g., “cafeteria
`phone”).
`While lists of authorized services and features may be
`stored in the user profile, it is possible for many ofthe features
`themselves to be fully or partially realized directly within the
`SIP phone 2046. Thus, a user could decline to subscribe to a
`certain service in the core IP network 202, but still obtain that
`service using the implementation on the SIP phone 2046.
`Assuming that a carrier or service provider ofthe network 200
`normally charges for that service, then this user would be
`acquiring it for free. As noted, one way to attempt to prevent
`this from happening is to extend or enhance the SIP protocol
`to support pas sing the information about the user’ s authorized
`services to the SIP phone, as described in US. patent appli-
`cation Ser. No. 10/243,642, entitled “Architecture and
`Method for Controlling Features and Services in Packet-
`Based Networks.” The SEP phone would then only invoke
`those services for which authorization has been received, i.e.,
`the SIP phone becomes the policy enforcement point on
`behalf of the core IP network 202.
`
`Network-Based Policy Enforcement of Intelligent-Client
`Features
`
`In the exemplary embodiment, an entity ofthe network 200
`is the policy enforcement point on behalf of the core IP
`network 202. The entity is a core-network-based policy
`enforcement point that is (1) in the communications path of
`substantially each and every call control and signaling mes-
`sage between any end-user client and any call control and
`signaling entity of the network 202 (including, possibly,
`another client device); and (2) able to communicate with, and
`set parameters of, network elements that monitor and control
`media data flow across network boundaries (e. g., border ele-
`ments 216 and 218). The policy enforcement point may rec-
`ognize all call control and signaling messages that pass
`through it, and filter them according to their content, includ-
`ing, but not limited to, sender, intended recipient, and mean-
`ing within the particular call control and signaling protocol
`(e. g., message type). In addition, the policy enforcement
`point may control media data flow, or augment and/or assist
`other network elements that have this function. Such control
`
`ofmedia data flow may include, but is not limited to, ensuring
`compliance of media streams with agreed-to bandwidth and
`other network resource usage.
`The policy enforcement point may facilitate network-
`based enforcement of service and feature privileges on a
`call-by-call basis, (1) during an initial setup phase of the call
`or session, based upon the filtering of call control and signal-
`ing messages; and (2) once the call, session, service, or fea-
`ture is allowed and/or established, based upon both filtering
`of subsequent call control messages, and the monitoring and
`enforcement of any relevant, negotiated media bandwidth
`and/or other network resource usage. Note that the term
`policy enforcement point is a reference to a logical localiza-
`tion of a set of tasks and functions that may actually be
`embodied in one or more physical devices, and/or in a dis-
`tributed manner.
`
`The network policy enforcement point may use informa-
`tion, if known, regarding authorized services and features of
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`the sender, and/or information, if known, regarding autho-
`rized services and features of the intended recipient, to pro-
`cess each call control and signaling message according to a
`policy or policies prescribed by the core IP network. The
`filtering of call control and signaling messages constitutes
`policy enforcement, and for each message may result in the
`message being forwarded on with or without alterations, the
`message being discarded with or without return of an error
`indication message to the sender, or the message being dis-
`carded with return of an option message to the sender, for
`example.
`For any given message for which the sender is an autho-
`rized subscriber to the core network, the sender’s user profile
`will be known to the network and thus available to the policy
`enforcement entity. In this case, policy enforcement will be
`applied according to the sender’s authorized services and
`features, even if the intended recipient is not a subscriber to
`the core networ