US 8,539,552 B1
`(10) Patent No.:
`a2) United States Patent
`Grabelskyetal.
`(45) Date of Patent:
`Sep. 17, 2013
`
`
`US008539552B1
`
`(54) SYSTEM AND METHOD FOR NETWORK
`BASED POLICY ENFORCEMENT OF
`
`INTELLIGENT-CLIENT FEATURES
`
`(75)
`
`Inventors: David Grabelsky, Skokie, IL (US);
`‘
`‘
`5
`
`:
`
`2001/0024436 Al*
`2002/0075844 Al*
`2002/0116643 Al*
`9002/0124112 AL*®
`2003/0081607 Al*
`2003/0093563 Al*
`2003/0177363 Al*
`
`........ 370/352
`9/2001 Barraclough et al.
`.. 370/351
`6/2002 Hagen .............
`
`. 713/201
`8/2002 Raanan etal.
`.. 709/246
`9/2002 Ts0 occ...
`. 370/392
`5/2003 Kavanagh...
`....
`“709/245
`5/2003 Young etal.
`9/2003 Yokota etal. ...
`.. 713/176
`
`
`2004/0029564 AL*
`anoep rpath rakeZurichne.
`2/2004 Hodge ws...
`». ASS/ALL
`
`
`
`
`
`
`ichael Forest,IL(US);Homeier, Lake 2004/0057188 A1l* 3/2004 Phillips et al. wo 361/119
`
`Guanglu Wang, Buffalo Grove, IL (US)
`2004/0193906 Al*
`9/2004 Daretal.
`...cccccces 713/200
`(73) Assignee: Hewlett-Packard Development
`OTHER PUBLICATIONS
`Company, L.P., Houston, TX (US)
`Request for Comments: 3303, “Middlebox communication architec-
`ture and framework,” MIDCOM Architecture and Framework, p.
`1-34 Aug. 2002.
`U.S. Appl. No. 10/243,642, Architecture and Methodfor Controlling
`Features and Services in Packet-Based Networks,p. 1-48, Sep. 2002.
`
`(*) Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 1045days.
`
`(21) Appl. No.: 10/671,375
`(22)
`Filed:
`Sep. 25, 2003
`:
`25,
`
`* cited by examiner
`Primary Examiner — Gilberto Barron,Jr.
`.
`:
`Assistant Examiner — Roderick Tolentino
`
`(51)
`
`(2006.01)
`
`Int. Cl.
`HOAL 29/06
`(52) U.S.CL
`USPC vicesssessseescsseseeteenees 726/4; 726/21; 709/225
`(58) Field of Classification Search
`USPC vac 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
`5,809,230 A *
`Q/1998 Pereira voces 726/35
`
`. 713/175
`6,446,206 B1*
`9/2002 Feldbaum .....
`
`9/2003 Glitho et al. occ 370/352
`6,625,141 B1*
`.......... 370/352
`6,667,971 B1* 12/2003 Modarressi etal.
`6678-735 BL*
`1/2004 Orton et al
`709/230
`
`.......... 709/229
`6,785,728 B1*
`8/2004 Schneideret al.
`
`7,136,373 B2* 11/2006 Ma wo cceceeeeenenee 370/352
`4/2007 Rowe w..ecccceceenene 725/144
`7,207,057 BL*
`
`ABSTRACT
`(57)
`A system and method for network based policy enforcement
`of intelligent-client features is provided. An operatorof an IP
`telephony and/or IP multimedia network may enforce autho-
`rization or privileges of intelligent end-userclients to utilize
`or invoke services in the network. A network policy enforce-
`mentpoint 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 knowledgeor authorization of the net-
`work. The network policy enforcement point
`receives
`messages, associates the message with a knownservice,
`makes a determination as to whether a beneficiary of the
`so
`:
`:
`:
`service is authorized to invoke the service, and then filters the
`messages based on the determination.
`
`25 Claims, 7 Drawing Sheets
`
`100
`
`™
`
`
`
`
`
`EE} 106e Intelligent Client|}(as
`
`106a
`
`=
`
`106b
`
`
`
`
`
`
`Local Packet
`Network
`106
`
`106¢
`Intelligent Client
`106d
`
`a
`
`Intelligent Client
`
`Apple Inc.
`Ex. 1018 - Page 1
`
`
`
`112.
`
`
`
`=
`
`
`eee
`Authentication &
`
`Authorization
`
`Signaling &
`Call Control
`108.
`
`7
`Network-based
`410
`
`Core Packet
`Newnes
`Border Element/ALG
`Border Element/ALG
`
`104a
`
`
`104b
`
`
`
`Apple Inc.
`Ex. 1018 - Page 1
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 1 of 7
`
`US 8,539,552 Bl
`
`
`
`
`
`
`
`
`
`
`
`—oo1
`
`poseq-yJOMJON9BuyyeuBbis
`
`SODIAI3BSfoljUOZ|]eD
`Le\uoHezLouny2UOHeo}USYINY
`
`
`
`
`
`
`
`9TynjuawalyJapiogS1vAuewalyJepsog
`
`OLL
`
`jaye9109801
`
`
`
`—=5,=rayJOMJON=ev0le9OL
`
`
`
`jey9eY|e907
`
`YIOMJON
`
`
`
`
`
`
`
`yayoe[e907
`
`yIOMJON
`
`
`
`
`
`WUal|DyUsHI/97u]bAYNDISA
`
`
`
`yUa!|D3UsH)];9}UY
`
`Apple Inc.
`Ex. 1018 - Page 2
`
`Apple Inc.
`Ex. 1018 - Page 2
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 2 of 7
`
`US8,539,552 BI
`
`
`
`
`
`uonezuoyny9UOHeoHUaYNY
`
`
`
`YIOMJONdl
`
`9109
`
`
`
`
`
`
`
`{e007
`
`YIOMJONdi
`
`
`
`
`
`
`
`
`a1eME-dIS
`
`HWEMId/LUN
`
`HEMOdIS/LVNABJEME-IS
`
`Ppeseq-yxIOMJONzoe
`
`SODIAIBS
`
`auouddis
`
`é¢JUNSIA
`
`auouddiS
`
`9Uu0uddiS
`
`eu0oudd
`
`Is
`
`AppleInc.
`Ex. 1018 - Page 3
`
`Apple Inc.
`Ex. 1018 - Page 3
`
`
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 3 of 7
`
`US 8,539,552 Bl
`
`START
`
`»— 300
`
`Associating signaling and/or call control message with a
`knownservice or feature
`
`302
`
`304
`
`Determining whether a sender and/or intended recipient
`of the messageis authorized to use and/or invoke the
`identified service or feature
`
`
`
`
`Filtering each signaling and/or call control message
`according to whetheror notthe identified service or
`
`feature is authorized for the sender and/or intended|3096
`
`recipient of the message
`
`
`
`308
`
`Communicating with one or more networkentities to
`ensure compliance with network resource usage
`
`CEND)
`
`FIGURE3
`
`Apple Inc.
`Ex. 1018 - Page 4
`
`Apple Inc.
`Ex. 1018 - Page 4
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 4 of 7
`
`US 8,539,552 Bl
`
`YAOMJON
`JOSS8901qaoepazUuy
`
`
`Ad1|0g
`
`
`
`Ayyuyjuewediojuy
`
`007
`
`vorcor
`
`
`
`OFaBei0j}sejeg
`
`welbold
`
`807916507
`
`vAYNSIA
`
`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 Bl
`
`uo|jezvoyinyguOHeUaYINY
`AxOlddIS
`
`JBAIVS
`
`BIBEMY-dIS
`
`oleMy-
`
`dis
`
`dis
`
`{eMeu4
`
`Zs
`
`emo.
`
`Jojpue
`
`LWN
`
`Jasp-pug
`
`wUdIID
`
`0S
`
`
`
`te
`
`BeatEynalsaaa
`
`BLS
`
`dIS42W0
`
`quiodpug
`
`*Bra)
`
`(quad
`
`yuawedojugAd1og
`
`uonemnByuosd[e907]
`
`AHug
`
`uondo
`
`80SYIOM}ONd]3109
`
`
`
`
`
`
`
`“|Bulpuedap‘sasseippeq][220]40jeqo|5
`
`
`
`
`
`if uoleinByuodLYN[290]|EUOndOUO
`
`ors
`
`
`
`
`
`
`
`YIOMJBNd]19Ie4DJ9YIOJO‘Je907]J9YIO‘9105
`
`SAYMNDIA
`
`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 Bl
`
`
`
`
`
`
`
`09YIOMJONd]2109
`
`Aluossaispped|[e207J
`(OMJOUBJOUlLYN)
`
`
`
`uolezwouynyABAIBS|JEMod14[JEModl44J9sp-pug9uoHeodusyynyAxOlddiSaIeMY-dIiS
`BIEMY-djS|HeeJ
`yulodpugyuawmaoiojugAaljoduoyeinByuog[e907
`
`
`
`‘B'8‘Sniaval|P09
`
`“B-a)Ayyuzuondo
`
`
`OFSYOMJONdi]491d419Y}OJO‘|e907]19410‘3105
`
`
`
`LVNpue;=909yuai|9
`
`
`
`
`diS43430
`
`(juaID
`
`9AYNDIA
`
`Apple Inc.
`Ex. 1018 - Page 7
`
`Apple Inc.
`Ex. 1018 - Page 7
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Sep. 17, 2013
`
`Sheet 7 of 7
`
`US 8,539,552 Bl
`
`
`
`uopezuounyJOAIOSWemes4|Weeds!Jasn-pug9UOHeoHUEUNYAxOlddiSaJeMy-dIS|SIEMY-dIS|LoJ
`
`
`
`
`
`diS4930
`
`Be‘Snigval(|WN|POL|dJojpue|!jual|D
`
`(jUaIID
`
`Ba)\uondo
`
`
`
`
`
`yuiodpuguonjeinbyuoyje907]
`
`80LOMIONd]2109ZOZAOMIONdi][2907
`
`
`sannugjuswesiojuqAdyjog
`
`
`:uonesnByuodLYN1290)|euoljdeuo
`
`
`
`«|Bulpuedap‘sassasppeqd][EDO]10jeEqo|9
`
`
`
`mL002
`
`
`
`OlZYAOMJONd]491UIeD49YIOJO‘}2907]48UIO‘a109
`
`
`
`
`
`ZAYNDIA
`
`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
`methodfor network based policy enforcementof intelligent-
`client features.
`
`BACKGROUND
`
`The emergenceof 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 numeroustele-
`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 exchanginginfor-
`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 servicesstill
`depend upon network-basedservers and support, so network
`providers are probably in no dangerofloosingtheir ability to
`sell services. But the trend towardintelligent, 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 intelligentclients.
`Therefore, if carriers and service providers are to maintain
`their ability to generate revenue for services offered or sup-
`portedin 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-userclients that are not owned or controlled by
`the network providers, thereby enabling potential bypassing
`by the enduser 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 ofwhetherthe sender or
`the recipient of the messages is authorized to invoke the type
`of service, andfiltering 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
`whichservicesthe user is authorized to use. This method also
`
`includes determining from the user profile whether the useris
`authorized to invoke the knownservice, and filtering the
`message based on whethertheuser is authorized to invoke the
`knownservice.
`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 mayfilter 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 userprofile 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.
`
`Theseas 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 referenceto the following drawings, in which:
`FIG.1 is a block diagram illustrating one embodimentof a
`network architecture for support of packet-based telephony
`and multimedia sessions and services accordingto 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
`enforcemententity that may carry out the method of FIG.3;
`FIG. 5 illustrates one embodiment of a SIP-awarefirewall
`functioning as the network policy enforcementpoint;
`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-awarefirewall
`
`and a SIP Proxy server functioning as the network policy
`enforcementpoint.
`
`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-userclients, the networks need to be able
`to recognize signaling and call control messagesandtransac-
`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 manybasic and
`advancedservices 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 U.S. 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,” whichis entirely incorporated by reference herein as
`if fully set forth in this description. This approachrelies on the
`ability of the client to support required protocol extensions,
`and to function as the policy enforcementpoint 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 authorizationorprivilegesof intelligent
`end-userclients 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 enforcementpoint
`is maintained in the network by elements that are under con-
`trol of the network operator. This approach lessens and/or
`eliminates a needfor the network operatorto police the selec-
`tion of client devices, and at the sametime, 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 embodimentof a network 100. It should be
`understoodthat 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.
`
`30
`
`40
`
`45
`
`The network 100 includes functionality of a packet net-
`workarchitecture for support of packet-based telephony and
`multimedia sessions and services. The network 100 includes
`
`50
`
`acore packet network 102, and twolocal 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 includesa signaling andcall
`control server 112, an authentication and authorization sever
`114, and a network-basedservices server 116. The signaling
`and call control server 112 intercepts call set-up messages
`sent between the end-userclients, e.g., intelligent client 104c,
`and the core packet network 102 and checks the authentica-
`
`4
`tion and authorization server 114 to determine whatservices
`the client may invoke. In turn, the signaling and call control
`server 112 may contact the network-basedservices 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 maybelocal 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
`connectsthe 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 notbe 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,1.e., access to the
`core packet network 102 first passes through somesort 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,
`becauseclients’ true addresses are hidden from entities out-
`side the local packet networks 104 and 106, which prevents
`surreptitious communications across the boundary between
`local and core networks.
`
`If address mappingis 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 packetnet-
`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 mayalternatively 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 Rosenberget 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 telephonecalls, videoconferences, and other
`multimedia connections. SIP can establish two-party sessions
`(ordinary telephonecalls), 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, andcall ter-
`mination. Other protocols, such as real time protocol (RTP)
`
`AppleInc.
`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 overthe 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 mayrepresent a user named John at
`the host specified by the domain name system (DNS) of
`3Com. SIP URLs mayalso 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 thefirst 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.
`
`TABLE1
`
`INVITEsip: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 linesthat follow are a list of header
`fields. For example, the fields Via (describing the address at
`whichthe useris expectingto receive responses), To (contains
`a display name or SIP request-URI towards whichthe request
`wasoriginally directed), From (contains a display name and
`a SIP request-URIthat 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-URIthat represents a direct route to contact the
`sender) are headerfields. 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 methodsare provided below in Table 2.
`
`TABLE 2
`
`METHOD
`
`DESCRIPTION
`
`INVITE
`ACK
`BYE
`OPTIONS
`CANCEL
`REGISTER
`
`NOTIFY
`REFER
`
`Requestinitiation of a session
`Confirm that a session has been initiated
`Request termination of a session
`Query a host aboutits 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
`REFERbenotified of the outcomeof the
`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 containsthe caller’s capabilities, media
`types, and formats. The INVITE messagealso 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
`wherethe 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
`
`50
`
`55
`
`60
`
`65
`
`The proxy server will read the INVITE message and may
`use a location service locally or remotely locatedto 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-URIin the INVITE
`message to one within a location database, which may be
`within another proxy server. The INVITE request is then
`forwardedto 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
`Axx
`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 aboutthe 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- and 206a-5, and SIP phones, such as SIP phone
`204c-d and 206c-e. The core IP network 202 includes a SIP
`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
`firewalls 216 and 218, which incorporate functionality spe-
`cific to SIP. Such devices are commonlyreferred to as SIP-
`awarefirewalls, 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 beyondits 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 somesort of veri-
`fication that authenticates the user and authorizesuse 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
`
`AppleInc.
`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. Assumingthe 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 userprofile
`might list services and features to which the user has sub-
`scribed, e.g., basic calls, call waiting, call forwarding,etc.
`Onceregistration is complete, the user may invoke services
`within the core IP network 202. Note that the user could be a
`
`8
`the sender, and/or information, if known, regarding autho-
`rized services and features of the intendedrecipient, 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 mayresult 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
`specific person, group, or generic identity (e.g., “cafeteria
`example.
`phone”).
`For any given message for which the sender is an autho-
`While lists of authorized services and features may be
`rized subscriberto the core network, the sender’s user profile
`stored in the userprofile, it is possible for many ofthe features
`will be knownto the network and thus available to the policy
`themselvesto be fully orpartially realized directly within the
`enforcemententity. In this case, policy enforcement will be
`SIP phone 204c. Thus, a user could decline to subscribe to a
`certain service in the core IP network 202, but still obtain that
`applied according to the sender’s authorized services and
`service using the implementation on the SIP phone 204c.
`features, even if the intended recipient is not a subscriber to
`
`Assumingthatacarrier or service providerofthe network 200 the core network, or is a trusted endpoint within the core
`normally charges for that service, then this user would be
`network. For example, the intended recipient could be a ser-
`vice element within the core network, or subscriber in another
`acquiring it for free. As noted, one way to attemptto prevent
`core network.
`this from happeningis to extend or enhance the SIP protocol
`to support passing the information about the user’s authorized
`services to the SIP phone, as described in U.S. 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
`
`For any given message for which the intended recipientis
`an authorized subscriber to the core network, the intended
`recipient’s user profile will be knownto the network and thus
`be available to the policy enforcemententity. In this case,
`policy enforcement will be applied accordingto the intended
`recipient’s authorized services and features, even if the
`senderis not a subscriber to the core network,or is a trusted
`endpoint within the core network. For example, the sender
`could be a service element within the core network, or a
`subscriber in another core network.
`
`25
`
`30
`
`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
`enforcementpoint 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,
`anotherclient 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, andfilter 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/orassist
`other network elements that have this function. Such control
`
`ofmedia data flow mayinclude, butis 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 phaseof the call
`or session, based uponthefiltering of call control and