`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 1 of 27
`
`EXHIBIT 2
`EXHIBIT 2
`
`
`
`USOO7486684B2
`
`(12) United States Patent
`Chu et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7486,684 B2
`Feb. 3, 2009
`
`(54)
`
`(75)
`
`(73)
`
`(*)
`
`(21)
`(22)
`(65)
`
`(51)
`
`(52)
`(58)
`
`METHOD AND APPARATUS FOR
`ESTABLISHMENT AND MANAGEMENT OF
`VOICE-OVER IP VIRTUAL PRIVATE
`NETWORKS IN P-BASED
`COMMUNICATION SYSTEMS
`Inventors: Thomas P. Chu, Englishtown, NJ (US);
`Martin Joel Glapa, Golden, CO (US);
`Francis Robert Magee, Lincroft, NJ
`(US); Steven H. Richman, Highland
`Park, NJ (US)
`Assignee: Alcatel-Lucent USA Inc., Murray Hill,
`NJ (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 976 days.
`Appl. No.: 10/674.885
`Filed:
`Sep. 30, 2003
`
`Notice:
`
`Prior Publication Data
`US 2005/OO68942 A1
`Mar. 31, 2005
`
`Int. C.
`(2006.01)
`H04L 2/56
`(2006.01)
`H04) 1/16
`U.S. Cl. ..................... 370/401; 370/352; 379/88.17
`Field of Classification Search ......... 370/352–356,
`370/400, 401, 466,467, 230, 389, 392; 709/231;
`379/88.17
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`7,369,556 B1* 5/2008 Rekhter et al. .............. 370,392
`2002/0150.083 A1* 10/2002 Fangman et al. .....
`... 370,352
`2002/0169887 A1* 1 1/2002 Melampy et al. .......... 709/231
`2003/0076815 A1 *
`4, 2003 Miller et al. ......
`... 370,352
`2003/01 17954 A1* 6/2003 De Neve et al. ............. 370,230
`
`OTHER PUBLICATIONS
`Network Working Group, Request for Comments: 2685, Category:
`Standards Track, B. Fox, Lucent Technologies, B. Gleeson, Nortel
`Networks, Sep. 1999, Virtual Private Networks Identifier; http://
`www.ietforg/rfc/rfc2685.txt?number=2685.
`* cited by examiner
`Primary Examiner John Pezzlo
`(57)
`ABSTRACT
`
`Establishing voice calls in an IP based VPN includes deter
`mining the relative location of a terminating point with
`respect to an originating point of a new communication con
`taining the Voice data, determining one or more IP addresses
`to egress the communication from the originating point to the
`terminating point, creating a VPN identifier in the new com
`munication, passing the new communication to the terminat
`ing point and removing the VPN identifier from the new
`communication. The VPN identifier can be an extra field
`added to an encapsulation coding scheme of the Voice data.
`
`16 Claims, 16 Drawing Sheets
`
`220
`
`200
`
`LOCAL
`SOFT-SWITCH
`IPADDRESSC
`
`SOFT-SWITCH
`FOR GATEWAY
`1304
`FOR INCOMING CALL,
`THE SOFT-SWITCH CANDENFY
`HEWPNLABEL FROM
`THE DALEONUMBER
`
`SERVICE
`PROVIDER'S
`PNETWORK
`Y
`400
`PSNT GATEWAY
`1302
`
`140-7
`/ LOCAL
`PACKET SWITCH
`210
`
`(est)
`
`s
`PSTNPHONE
`1301
`
`
`
`CALPHONE
`SUBSCRIBER
`IPADDRESS A1
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 2 of 27
`
`a
`
`Y
`
`M
`/
`---
`M
`/ ENCAPSULATION WILL BE USED \
`WOCE
`PACKE
`RTP
`--
`UDP
`
`WOICE
`PACKET
`RTP
`UDP
`
`IPADDRESS
`
`LOWERLAYER
`
`IPADDRESS
`
`WPN-ID
`
`n- 306
`
`LOWERLAYER
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 1 of 16
`
`US 7486,684 B2
`
`
`
`GATEWAY 130
`
`PSTN
`
`PPHONE 103
`
`LOCAL AREANETWORK 120
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 3 of 27
`
`FIG. 1
`(PRIOR ART)
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 4 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 4 of 27
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 2 of 16
`
`US 7,486,684 B2
`
`
`
`ONNWNOIS502
`
`
`
`SHHOLIMS-14OS|07|USHLOOLL--HOLIMS-140S|!sgovssantT|Pe|
`
`MYOMLANENS
`
`—|diona|S3OVES3W
`
`
` |SMOWLYSA!YOTOULNOD o1)yanyas
`TOYLNOD|ONITYNOIS
`
`ONITWNOIS||
`
`MYOMLANdi
`
`
`
`SAODIANASVLVG
`
`MYOMLANENS
`
`
`GO0¢4dId4OWaLNFD|YACIAONd
`
`SOIAYNAS|
`
`
`
`JOWIMSLNI.
`
`
`
`
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 3 of 16
`
`US 7486,684 B2
`
`
`
`0ZZ HOLINAS-||-|OS
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 5 of 27
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 4 of 16
`
`US 7486,684 B2
`
`
`
`
`
`O0?. ZHO LIWAS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 6 of 27
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 5 of 16
`
`US 7486,684 B2
`
`
`
`OZZ
`
`HO L?MS-L-HOS
`
`
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 7 of 27
`
`OSDOT SDNSSBOOC
`
`
`
`NO? 10BNNOO
`
`Z09
`
`
`
`NOH LOENNOO
`
`
`
`U.S. Patent
`
`US 7486,684 B2
`
`
`
`| OZZ HOLINAS-L-JOS I
`
`
`
`|O=SSERHCICIW CHÍ|
`
`L
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 8 of 27
`
`
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 9 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 9 of 27
`
`U.S. Patent
`
`ONILVNIWYALOL
`
`O=SSsayddVvdlLa=SSaydavdiO=SSaydavdl
`
`HOLIMS-L4OS
`
`0zS
`
`
`
`SSIYDI—gig
`
`ZOSSAYONI
`
`HOLIMS-LIOS
`
`
`
`
`
`Feb. 3, 2009
`
`YSAYaSXad-diONILVNISIYOWOYS
`
`Sheet 7 of 16
`
`US 7,486,684 B2
`
`
`
`
`
`LANOVdLAaxNoOVdLAXOVd
`
`
`
`
`
`HOLIMSHOLIMSHOLIMS
`
`OLE
`
`OLSOlLPOle
`
`d=SSSYddOVvdlbd=SSAYdOVdl€@=SSAYCCVdi
`
`
`
`002Z°Ol4
`
`
`
`
`
`SS3dy93LISNVYLSSSYONI
`
`OVS
`
`NOILOANNOO
`
`
`
`NOILOANNOONOILOANNOO
`
`
`
`YSAYASXdd-dl
`
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 10 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 10 of 27
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 8 of 16
`
`US 7,486,684 B2
`
`NOLLWNILSAC||||H=SSSNGQVdl:109SNOHddl|||||||20;OvS|INOLLOANNOO;
`jl||||9z9:||||9z9|eB
`:rSSauaaydl:|208HaANaS!||||LoJ
`:908SASINSUd|!YSNOLSND
`
`708S301ds40TWHLNGO|
`||||oeeeI
`0€9229
`
`5=SSAYAVdi
`—_=
`ThC)Orr!
`
`
`
`29
`
`002
`
`SSayoa
`
`HOLIMS-140S
`
`02S
`
`;“slg
`
`”TX
`
`E8c9
`
`d=SS3YdCVdl
`SS3UNOS*
`
`S$Saduy94
`
`LAyNoVd
`
`HOLIMS
`
`OLS
`
`NOILOANNOO
`
`WOVE-ONIY|SLOWS
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 11 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 11 of 27
`
`Sheet 9 of 16
`
`U.S. Patent
`
`|208YaAYaS|veg||02SHOLIMS-L4OS|||ssayuogl|||||S=ssaudavdl|booJLo_I
`
`Feb. 3, 2009
`
`
`
`|||ze9|| g€9||||l|veg|8e9||Oo
`
`US 7,486,684 B2
`
`6Sls
`
`Se|pe!aweove|hannoNOLLOANNOO
`
`|||HOLIMS|ly||j109ANOHddl||130dWOVE-ONIY|a>|SS3u9F|SLOWSY
`
`
`
`
` 002/908SASIWSUd|770831440TVULN39||YASWOLSND
`NOILVNILSAG!j=seauaayaissauoa
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 12 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 12 of 27
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 10 of 16
`
`9=SSayaaydiLa=SsSayaavdl9=SSaNaavdl
`
`
`
`HOLIMS-L40SHOLIMS-L40SHOLIMS-LAOS
`
`
`
`
`SsaHog869LISNVELLchoSSSUONI
`
`NOILOSNNOO
`
`NOILOANNOD
`
`NOILOSNNOO
`
`ozs
`
`0cP,0c2
`
`ONILVNIWYSLOL
`
`
`
`YAANSSXdd-dl
`
`ONILVNIDINOWON
`
`
`
`YSANASXEd-dl
`
`US 7,486,684 B2
`
`
`
`
`
`HOLIMSHOLIMSHOLIMS
`
`OLSOLPOle
`
`d=SSAYCOQVdiLd=SS3SYdOvdld@=SSAYCOVdl
`
`OlSls
`
`
`
`
`
`LAWOVdLAWOVdLaxOVd
`
`OvS
`
`Ove
`
`SSAYONI
`
`SS3yo4LISNVYL
`
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 13 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 13 of 27
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 11 of 16
`
`US 7,486,684 B2
`
`MYOMLANENS
`
`dlOA
`
`Ole
`
`NOLLOANNOS!|8r9||vr9||||||||||||||||||||TTTr|zg022!||HOLIMS-L40S|||||||iLO=SSSYaqVdl,bo5
`FO~7I7]!G0Z3Old40
`||fl|Orz|OPL||:NOILOANNOD
` USWOLSND|MACIAONdSOIANSS||=SSRHCQYdi|g=ssaucavdioz:|LOLSNOHddi!HOLIMS!‘el!1ayOVd|Ioath|||
`
`WHLNSO|!SOLSASINSud
`
`LLOld
`
`||
`
`
`
`
`
`U.S. Patent
`
`US 7486,684 B2
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 14 of 27
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 15 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 15 of 27
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 13 of 16
`
`US 7,486,684 B2
`
`
`
`‘I1¥0ONINOONIHOS
`
`WOU1391NdASHE
`
`
`
`SMACIAOdd
`
`YYOMLANdi
`
`00P
`
`
`
`
`
`SNOHdNiSdAVMALVOINSd—\TW9OTSNOHdONITIVO
`
`
`
`\uzyLvSSSUNCQVdi\/LOelZ0EL\HOLIMSLB4OWd—_/Sagiesans
`
`ASLLNAGINVOHOLIMS-L4OS3HL
`
`YASWONGaTVIGSHLAOIANSS
`HOLIMS-LJOSel‘Old
`AWMALVDHOSsOW201
`0Poel_4)_HOLIMS-L408
`
`eraaaaeLayWoVd
`LIWDVd
`ADIOAADIOA\GaASn398THMNOLLVINSdVONAy
`
`
`YSAV1YAMOT
`
`9OEL
`
`GI-NdA
`
`
`
`YSAVTYSMO1
`
`
`
`SSAuyaaydl
`
`SS3YdGVdil
`
`
`
`
`
`U.S. Patent
`
`US 7486,684 B2
`
`
`
`
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 16 of 27
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 17 of 27
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 17 of 27
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 15 of 16
`
`US 7,486,684 B2
`
`
`
`vorl
`
`
`
`S$dy94SSAYONI
`
`OLSOle
`
`
`
`WOusSSaXdaVvdi
`
`
`
`
`HaaIHSSENs/\LOLLj\3NOHdGaorssauaavdl/\2SsaHdavdlSNOHdONITIVO
`
`ASSSHAQVdlFOAMSwagIMoSaNs
`NWIzuagldosans|wagiuosans
`
` /0zS\/02¢\/\/\/\!\gasnSi2¥aelyosansgasnSidvdsGasnSibYAsINOSENs
`WOdsSSAYCOVdiSMACIAONdSOIANSS«=WOSSSYAYdl
`HOLIMS-L4OS/\HOLIMS-140S
`
`
`
`
`HOLIMSL3NOVdHOLIMSLaWoVd
`\SMSCIAOYd/VvSSSUGQYdi
`
`
`
`HLIMLaxoVdSDIOA
`
`YalsILNSG!NdAWldAdS
`
`qrlSls
`
`
`
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 16 of 16
`
`US 7486,684 B2
`
`
`
`
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 18 of 27
`
`
`
`US 7486,684 B2
`
`1.
`METHOD AND APPARATUS FOR
`ESTABLISHMENT AND MANAGEMENT OF
`VOICE-OVER IP VIRTUAL PRIVATE
`NETWORKS IN P-BASED
`COMMUNICATION SYSTEMS
`
`FIELD OF THE INVENTION
`
`The invention relates to the field of communications sys
`tems and more specifically to the management and control of
`voice-over Internet Protocol (VoIP) virtual private networks
`(VPNs) in an IP-based public branch exchange (PBX) envi
`rOnment.
`
`10
`
`DESCRIPTION OF THE BACKGROUND ART
`
`15
`
`2
`alternative is similar to the “Software Defined Network” ser
`vices from the SPS where TDM based PBXs are connected to
`the SP's networking using the Primary Rate Interface (PRI)
`from the ISDN. We will refer to this alternative as VoIP-VPN.
`The module in this network that handles call signaling from
`the user is commonly referred to as a soft-switch. Depending
`on the size of the network, a network may contain a number of
`soft-switches, which are interconnected. Call signaling mes
`sages route through a series of soft-switches in order to estab
`lish a call as it is more efficient to connect the IP PBXs
`through an IP network, without converting the voice traffic to
`TDM and back.
`In the current state of the art, all the IP phones are assigned
`an IP address from the SP's IP address space. However, this is
`a major shortcoming. Most enterprises use their own IP
`addressing scheme in addressing their workstations and PCs.
`All IP-VPN services allow the customer to use their own IP
`address scheme. Customer would like any VoIP-VPN service
`to have the same capability, i.e., the IP phones can be assigned
`IP address from the customer IP address space instead of the
`SP's public IP address space. This capability is important as,
`in the future, that an IP phone would actually be part of a PC
`or workstation. In this case, it is paramount that the PC and the
`IP phone use the same IP address or, at least, use IP address
`from the same addressing space. This invention describes an
`innovative method to do this.
`
`SUMMARY OF THE INVENTION
`
`The disadvantages heretofore associated with the prior art
`are overcome by a novel method for establishing and manag
`ing voice call traffic in an VoIP IP virtual private network. The
`method comprises, in one embodiment, determining the rela
`tive location of a terminating point with respect to an origi
`nating point of a new communication containing the Voice
`data, determining one or more IP addresses to egress the
`communication from the originating point to the terminating
`point, creating a VPN identifier in the new communication,
`passing the new communication to the terminating point and
`removing the VPN identifier from the new communication.
`The VPN identifier is an extra field (such as an MPLS label)
`added to an encapsulation coding scheme of the Voice data. In
`an alternate method, the packet Switches (or special gateway)
`can perform address translation from an IP address from one
`IP address space to an IP address from another IP address
`space of the Voice data.
`An apparatus for IP-based VPN communications includes
`at least one soft-switch and at least one packet Switch having
`an interface to said at least one soft-switch. The packet Switch
`has a VPN processing module for selectively establishing a
`VPN based on a selection of originating and terminating IP
`addresses of Voice calls passed to the at least one soft-switch
`and at least one packet Switch. In one embodiment, the at least
`one soft-switch is an ingress Soft-switch and an egress Soft
`Switch. Similarly, the at least one packet Switch is an ingress
`packet Switch and an egress packet Switch. The apparatus may
`further include a PSTN gateway connected to a gateway
`soft-switch and said at least one soft-switch for processing
`“off-net calls. The apparatus may further include an inter
`VPN gateway disposed between an ingress packet Switch and
`an egress packet Switch. The inter-VPN gateway passes pack
`ets of voice data from an originating point from one subscrib
`
`IP based PBX has gained acceptance and momentum in the
`market place of advanced, high speed communications. The
`architecture of an prior art IP-PBX system is seen in FIG. 1.
`The system 100 consists of a number of IP phones (101, 102,
`103) which are connected to a local area network (LAN) 120.
`Connected to the LAN is a server 110 which provides control
`of the local telephony network. The server 110 communicates
`with IP phones (101, 102,103) via IP messages, accepts call
`requests from the IP phones (101, 102, 103) and alerts the
`phones upon incoming calls. There are two common stan
`dards for this protocol: H.248 from the International Tele
`phone Union (ITU) and Session Invitation Protocol (SIP)
`from the Internet Engineering Task Force (IETF). The intel
`ligence of the system 100 resides in the server 110 which can
`provide enhanced services Such as call waiting, call hold, call
`transfer and the like.
`In IP-PBX, voice traffic is encapsulated inside IP packets
`and is carried between the IP phones using the LAN. For
`communications to phones in the public Switched telephone
`network (PSTN), a gateway 130 is needed to convert the IP
`encapsulated voice traffic to the traditional time division mul
`tiplexed (TDM) format. The gateway 130 is also under con
`trol of the server 110 using H.248. The usual access protocol
`between the gateway 130 and the PSTN is ISDN PRI. Many
`40
`traditional PBXs have been upgraded to have an IP interface
`to support IP phones. These PBXs are considered as IP-PBX
`in this convention.
`As IP-PBXs are created, the need to connect all the PBXs
`within an enterprise together to form a corporate network
`45
`exists (just as it did with respect to TDM based systems). An
`advantage in connecting two IP-based PBXs is that the voice
`traffic is already packetized. Direct packet-to-packet connec
`tivity is desirable as there is no need to convert the voice
`packets to TDM and back to again. A packet to TDM gateway
`is not necessary for calls between the IP-PBXs. This results in
`cost reduction and improvement in the performance of the
`system, as this avoids costly packet to TDM conversion and
`Vice versa.
`In one of the approaches to interconnect IP-PBXs, the user
`Subscribes to connection oriented packet services, such as
`frame relay and ATM permanent virtual circuit services, from
`a service provider (SP). The SP would only provide transport
`services for the packet and is not aware that the packets are
`Voice packets. In an alternate approach in which the SP can
`provide added functionality, the SP would actively participate
`in the call signaling when a call is being in set up. In doing so,
`the SP can provide enhanced service at the request of the
`end-user on a call-by-call basis. As the SP network is aware of
`when calls are set up and torn-down, the service can be
`charged based on call duration. This may result in lower cost
`to the end-user, another benefit. In the TDM environment, this
`
`25
`
`30
`
`35
`
`50
`
`55
`
`60
`
`65
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 19 of 27
`
`
`
`US 7486,684 B2
`
`3
`er’s VoIP-VPN to a terminating point of another subscriber's
`VoIP-VPN, modifying the VPN identifier appropriately.
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`4
`subscriber can negotiate the per-minute cost with the SP
`which usually results in cost saving. The subscribers can use
`many of the enhanced features provided by the SP. The Sub
`scriber can leave the detailed engineering and maintenance of
`the network to the SP. The SP offers a VoIP VPN service that
`allows such SP's to keep the traffic of the high-end subscrib
`ers on their network. These subscribers, in general, have a
`tendency to subscribe to many enhanced services, which have
`high margin. Another benefit to the subscriber is that the SP
`can charge the service based on usage (e.g. minutes of use). In
`many instances, the SP can provide attractive rates which
`results in substantial savings to the subscriber.
`A useful feature of the VoIP VPN service is that the SP
`provides gateway functionality to the PSTN. This function
`ality renders the traditional packet-to-TDM gateway of the
`IP-PBX unnecessary. This reduces the system cost of the
`IP-PBX, both in capital spending and future maintenance.
`Also, an inter-VPN gateway would be another useful feature.
`The inter-VPN gateway forwards voice packets from one
`VPN to another directly, without conversion to TDM first.
`Additionally, the same architecture also applies to other voice
`over packet technologies such as ATM with slight modifica
`tion, and not just VoIP.
`FIG. 2 depicts a portion of an exemplary communications
`system 200 in one embodiment of the subject invention. The
`system 200 comprises a Customer Premise 105 having a
`plurality of IP phones (101, 102, 103) and a server 110 con
`nected to a VoIP-VPN SP at the SP's central office 205.
`Connection 145 is the connection between the customer 105
`and CO 205, and is made via one or more routers 140. In one
`embodiment of the invention, the subscriber (at the Customer
`Premise) uses their own IP address in assigning IP address to
`their devices. To increase reliability, dual access to the SP is
`possible (such as via a second connection 155 shown in
`broken line format).
`The router 140 at the Customer Premise 105 is connected to
`a special media gateway 210 at the SP's central office. This
`media gateway 210 accepts voice packets from an incoming
`interface and switches these packets to an outgoing interface.
`In H.248 terminology, all the terminations of this special
`gateway are packet terminations, i.e. ephemeral terminations.
`Although the voice traffic remains in packet form, its encap
`sulating scheme may change (e.g. from IP to ATM, or from IP
`V4 to IP V6). Even if the packet encapsulation scheme
`remains the same, header information may be changed (e.g.
`one IP address to another IP address). We refer to this type of
`media gateway 210 as a packet switch.
`Also located at the SP central office is a soft-switch 220.
`Server 110 at the Customer Premise 105 will communicate
`with the soft-switch 220 with an agreed upon signaling pro
`tocol. Examples of suitable protocols used are selected from
`the group consisting of H.248 and SIP. The soft-switch 220,
`based on requests from the server 110 or peer soft-switches
`(explained in greater detail below), sends the appropriate
`commands to packet switch 210 to set up the appropriate
`cross-connects. Such interaction between the soft-switch 220
`and packet switch 210 is managed by a control interface (i.e.,
`a vertical control interface) 215 (described in greater detail
`below). The soft-switch is the intelligence of the system. It
`contains all the information regarding the subscribers VPNs.
`For example, it keeps track of the VPN that a location belongs
`to, the dial plans of the subscribers, the VPN identifier for an
`VPN (or a particular interface) and the like. The soft-switch
`can be implemented in a distributed manner in that its data
`base may be housed in a different physical unit than its pro
`cessing logic modules oras a single unit. For simplicity, in the
`following descriptions, the soft-switch represents the entire
`
`15
`
`25
`
`The teachings of the present invention can be readily
`understood by considering the following detailed description
`in conjunction with the accompanying drawings, in which:
`FIG. 1 depicts a general overview of a prior art IP-PBX
`configuration;
`10
`FIG. 2 depicts a general overview of a portion of a com
`munication system in one embodiment of the subject inven
`tion;
`FIG.3 depicts an abbreviated view of the system of FIG. 2
`to highlight a packet classifier feature:
`FIG. 4 depicts a general architecture of a transport network
`which is connected to the communication system of the Sub
`ject invention;
`FIG. 5 depicts a detailed view of a packet switch in one
`embodiment of the subject invention;
`FIG. 6 depicts a flow diagram of forward signaling of a call
`in the ingress soft switch of the system;
`FIG.7 depicts a flow diagram of forward signaling of a call
`in the transit network;
`FIG. 8 depicts a flow diagram of forward signaling of a call
`in the egress soft switch;
`FIG.9 depicts a flow diagram of return signaling of a call
`in the egress soft switch;
`FIG. 10 depicts a flow diagram of return signaling of a call
`in the transit network;
`FIG. 11 depicts a flow diagram of return signaling of a call
`in the ingress soft Switch of the System;
`FIG. 12 depicts encapsulation schemes of voice packets in
`one embodiment of the subject invention;
`FIG. 13 depicts a configuration of a call from the VPN to
`the Public Switched Telephone Network in one embodiment
`of the subject invention;
`FIG. 14a depicts a configuration of a call from a first VPN
`to a second VPN in one embodiment of the subject invention;
`FIG. 14b depicts a configuration of a call from a first VPN
`40
`to a second VPN in a second embodiment of the subject
`invention; and
`FIG. 15 depicts a configuration for a call between two
`locations on the same VPN where address translation is used
`to transfer traffic in the subject invention.
`To facilitate understanding, identical reference numerals
`have been used, where possible, to designate identical ele
`ments that are common to the figures.
`
`35
`
`45
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 20 of 27
`
`DETAILED DESCRIPTION
`
`The subject invention specifies a network architecture for
`providing a voice over IP virtual private network (VoIP VPN)
`service to a subscriber and a method of establishing such a
`VoIP VPN. The VoIP VPN service connects all the IP-PBXs
`of a subscriber into a single logical network. In one embodi
`ment, the present invention provides a virtual private network
`service where subscribers can use their own internal dial plan.
`This does not preclude each IP phone from being assigned its
`own E. 164 number (the international standard dial plan) and
`receiving calls from the PSTN directly. Similarly, a sub
`scriber can use their own IP address assignment plan in
`assigning IP addresses to the IP-PBX server and the IP
`phones. The VoIP VPNs from all the subscribers share a
`common physical network.
`Connecting IP-PBXs together to form a corporate network
`has many advantages to the SP and subscribers alike. The
`
`50
`
`55
`
`60
`
`65
`
`
`
`6
`advantages of putting the VoIP-VPN traffic on separate layer
`2 tunnels include: (1) the ability to engineer the tunnels to the
`desired QoS level; (2) an ease insecurity administration as the
`traffic is separated and different policies can be applied to the
`VoIP-VPN traffic; and/or (3) diverse routing is dynamically
`Supported on a per call basis. Calls to the same place can be
`forwarded differently by mapping them to different layer 2
`tunnels.
`FIG. 4 depicts the general architecture of a transport net
`work 400 which is connected to the system 200. Packet
`switches 210 of various SP central offices are connected to
`each other through a network310 via connection to a plurality
`of network core packet switches 402. In some embodiments
`of the invention, tunnels are used in order to provide a guar
`anteed level of quality of service as the tunnels can be engi
`neered more easily. Examples of Suitable tunneling tech
`niques are frame relay permanent virtual circuit (PVC), ATM
`PVC, MPLS labeled switched path (LSP), IP tunnels and the
`like. Tunnels based on other higher layer protocols are con
`sidered layer-2 connections as these tunnels functionally pro
`vide point-to-point connectivity (layer 2 functions).
`Note that the invention does not preclude direct logical
`connection between two "edge’ packet switches 210. In fact,
`this is the case if the traffic volume between two packet
`Switches warrants such a connection. More specifically, the
`invention Supports both direct as well as consolidated (via
`core packet Switches 402) connection. In addition, connec
`tivity between the customer premise router 140 and the edge
`packet switch 210 as well as between packet switches do not
`necessarily need to be based on tunnel technologies. The
`invention also supports regular connectionless IP. However,
`in the latter case, quality of service may not be guaranteed.
`A well accepted standard for the vertical control interface
`215 between a media gateway controller (or soft-switch 220)
`and a media gateway (or packet switch 210) is the H.248
`specification from the ITU, though others may be used. As
`there are many different types of media gateways, the H.248
`recommendation provides the means for the industry to
`extend the specifications to support the different types of
`gateways. These extensions are referred to as "packages'.
`The packet switch 210 can be considered as a specific type of
`gateway where all the terminations are ephemeral (non-per
`manent). This following description specifies the functional
`characteristics of the interface between the soft-switch 220
`and the packet Switch 210, and can be implemented as a
`package of the H.248 specification. Other embodiments of
`H.248 are also possible.
`The structure of the packet switch 210 is described herein
`for illustrative purposes only using the terminology of H.248.
`The logical structure of the packet switch 210 that manages
`voice traffic is depicted in FIG. 5. The packet switch 210 is
`provided with a plurality of layer-1 (physical) or layer-2
`(logical link) connections 502, 504, 506. The peer of these
`connections can be routers 140 at customer premises 105,
`routers within the SF's IP network, and other packets
`switches (210 or 402). Each connection carries a number of
`voice calls. Each of the voice calls (denoted by arrows extend
`ing from the plurality of connections 502,504 and 506 into
`the packet switch 210) passes through a VPN Processing
`Logic Module 510. The VPN Processing Logic Module 510
`decides how to establish the VPN based on the originating and
`destination addresses in the call signaling information (dis
`cussed in greater detail below). The maximum number of
`allowable calls for each connection depends on the amount of
`network resources allocated and the nature of the calls (coder,
`silence Suppression, etc.). The soft-switch 220 manages the
`
`Case 6:20-cv-00272-ADA Document 69-3 Filed 04/08/22 Page 21 of 27
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`US 7486,684 B2
`
`10
`
`15
`
`25
`
`5
`system, containing all the necessary modules such as signal
`ing, control logic, service logic, database and the like.
`In general, the subscriber would subscribe to many ser
`vices from the same SP, both data services as well as voice
`services (i.e., integrated access) via the first and second con
`nections 145 and 155. It is the SP's responsibility to separate
`the packets and direct them to the appropriate network equip
`ment that Supports the individual services. The separation
`function that separates all packets based on Some criteria is
`referred to as packet classification. FIG. 3 depicts an abbre
`viated view of the communication system 200 for the pur
`poses of focusing on packet classification. In most cases,
`packet classification is performed in the packet switch 210.
`Both data and voice traffic is sent from the Customer Premise
`105 to the packet switch 210. The packet switch 210 classifies
`the packets and forwards all VoIP-VPN voice packets to a
`VoIP network (and vice versa). The VoIP network carries both
`on-net (within the same VoIP VPN) and off-net (to PSTN)
`calls. Packet switch 210 also forwards other packets to the
`appropriate services.
`In some implementations, a packet classifier 302 is exter
`nal to the packet switch 210. One or more tunnels 300x are
`established between packet classifier 302 and the packet
`switch 210. The packet switch 302 forwards all voice traffic to
`the packet switch 210 through these tunnels 300x. In short,
`packet classification is a function of a logical module which
`can be external or internal to the packet switch 210.
`In one embodiment of this classifier 302, each access inter
`face has an associated table whose entries consist of destina
`tion and origination IP-address/UDP port pairs with protocol
`type UDP. The entries are dynamically created and deleted
`based on the call signaling. The table is created when a call is
`set up and deleted when a call is torn down. Packets matching
`any one of the entries will be forwarded to the logical module
`that handles the VoIP-VPN logic. Otherwise, packets are
`processed as non VoIP-VPN traffic.
`As the number of the active phones rise even during busy
`hours, the classification table is relatively small. If memory
`and performance are concerns, many alternative algorithms
`are possible, but at the expense being more rigid. For
`example, all VoIP-VPN traffic can be assigned a diffServ
`(RFC 2474) code point (DSCP) and the classification may
`key on this code point. In this example, the classification table
`is a single entry, the DSCF. However, the subscriber has to
`ensure no other applications or services use this DSCF value.
`An alternate method is to use an IP subnet mask. This implies
`that all IP-phones, and only IP-phones, belong to this IP
`subnet.
`The classification process is performed at the first point of
`entry to the SP's network. If the first point of entry is the
`50
`soft-switch 220, information to build the classification table is
`already embedded in the vertical control protocol between the
`soft-switch 220 and the packet switch 210 and no additional
`protocol is needed. If the first point of entry is another device,
`that device needs to Support the classification module and to
`be under Soft-switch control. VoIP-VPN traffic is forwarded
`to the packet switch 210 via a plurality of tunnels 300x such
`as but not limited to MPLS LSPs. An embodiment of this
`control protocol is H.248 using an enhanced package that
`Supports this function.
`It is not necessary for the Subscriber to classify packets at
`their premises. However, it may be advantageous to do so in
`some instances. The classifier 302 allows the same architec
`ture as the one at the SP central office and is under the control
`of the IP-PBX server. After classification, the subscriber can
`put the VoIP-VPN traffic in tunnels (for example, a dedicated
`layer 2 tunnel) and transfer the packets to the SP. Certain
`
`30
`
`
`
`US 7486,684 B2
`
`5
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`7
`number of active calls over a specific connection. Calls are
`identified as call terminations within packet switch 210.
`When the soft-switch 220 needs to establish a cross-con
`nect (e.g. connect a VoIP call between two connections), it
`sends commands to the packet Switch 210 at the appropriate
`time to perform the following tasks: (1) create a context for
`the call; (2) add appropriate ephemeral terminations to the
`context; and (3) cross-connect the terminations within a con
`text in the appropriate time.
`The command to create context, add terminations to con
`texts and specifying the media flows within a context already
`exists in H.248. However, a new package is necessary to
`specify the naming convention for terminations. For the
`packet switch 210, a termination can be specified by two
`parameters, Connection End Point and Call Terminations.
`The Connection End-Point parameter identifies the connec
`tion that the packets come from (or exit to) via the plurality of
`connections 502, 504,506. The parameter has three fields: a
`Layer 1 identifier, a Layer 2 identifier and a Mode. The Layer
`1 identifier identifies the physical interface of the connection.
`Its structure may depend on the implementation of the packet
`Switch (e.g., slot number and port number). For simplicity, the
`interface number of the Interface SNMP MIB can be used to
`identify the interface. This assumes the existence of the Inter
`face MIB. Lay