`
`(12) United States Patent
`Chu et a].
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 7,486,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 IP-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)
`Alcatel-Lucent USA Inc., Murray Hill,
`NJ (US)
`
`Assignee:
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 976 days.
`
`Appl. N0.: 10/674,885
`
`Filed:
`
`Sep. 30, 2003
`
`Prior Publication Data
`
`US 2005/0068942 A1
`
`Mar. 31, 2005
`
`Int. Cl.
`(2006.01)
`H04L 12/56
`(2006.01)
`H04] [/16
`US. Cl. ................... .. 370/401; 370/352; 379/8817
`Field of Classi?cation Search ....... .. 370/352i356,
`370/400, 401, 466, 467, 230, 389, 392; 709/231;
`379/8817
`See application ?le for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5/2008 Rekhter et al. ............ .. 370/392
`7,369,556 B1 *
`2002/0150083 A1* 10/2002 Fangman et al.
`370/352
`2002/0169887 A1* 11/2002 MeLampy et al.
`709/231
`2003/0076815 A1* 4/2003 Miller et al. .... ..
`370/352
`2003/0117954 A1* 6/2003 De Neve et a1. ........... .. 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 Identi?er; http://
`www.ietf.org/rfc/rfc2685.D<t?number:2685.
`
`* cited by examiner
`
`Primary Examinerilohn 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 identi?er in the new com
`munication, passing the new communication to the terminat
`ing point and removing the VPN identi?er from the new
`communication. The VPN identi?er can be an extra ?eld
`added to an encapsulation coding scheme of the voice data.
`
`16 Claims, 16 Drawing Sheets
`
`LOCAL
`SOFT-SWITCH
`
`SOFT-SWITCH
`220 E FOR GATEWAY
`1304 /FOR INCOMING CALL,
`THE SOFT-SWITCH CAN IDENTIFY
`THE VPN LABEL FROM
`THE DIALED NUMBER
`
`SERV‘CE
`PROVIDER'S
`1P NETWORK
`4_<>0
`)
`LOCAL
`PACKET SWITCH\
`210
`\
`\
`\
`\
`\
`// ENCAPSULATION WILL BE USED \
`VOICE
`VOICE
`PACKET
`PACKET
`RTP
`RTP
`UDP
`UDP
`
`CALL'Z‘gPHONE
`SUBSCRIBER
`IP ADDRESS A1
`\
`
`/
`,
`/
`/
`/ W
`
`PSNT GATEWAY
`1302
`
`PSTN PHONE
`1301
`
`J
`
`IP ADDRESS
`
`LOWER LAYER
`
`lP ADDRESS
`
`VPN-ID V 1306
`
`LoWER LAYER
`
`PETITIONER APPLE INC. EX. 1006-1
`
`
`
`US. Patent
`
`Feb. 3, 2009
`
`Sheet 1 0f 16
`
`US 7,486,684 B2
`
`m
`
`PRI
`
`PSTN
`
`GATEWAY 130
`
`IP PHONE 103
`
`LOCAL AREA NETWORK 120
`
`FIG. 1
`(PRIOR ART)
`
`PETITIONER APPLE INC. EX. 1006-2
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61f02LI.6ehS
`
`US 7,486,684 B2
`
`n=o>
`
`mz:<zo_m
`
`mmo<mwms__IIIIIIIIIIIIIIIIIIIL
`
`mm_:o:>>m-Eom_\cum
`
`
`
`E150....._\\\I0._._>>w-._.n_Ow
`Iflul_xmozfimzmam_.1_______
`
`.I|l
`
`m__§Em_>_
`
`_
`
`
`
`m_o<wmm_2mz_._<zmWI
`
`xmozcmzn:
`
`
`
`mm_o_>mmm<._.<Q
`
`xmozfimzmzm
`
`--aN.m_.o._m%.w.z.E
`
`mmo_>omn_m_o_>mm_m_
`
`SE28.
`
`wouEmm:z__9:
`
`PETITIONER APPLE INC. EX. 1006-3
`
`
`
`US. Patent
`
`Feb. 3, 2009
`
`Sheet 3 0f 16
`
`US 7,486,684 B2
`
`
`
`65200 505m;
`
`2N
`
`
`
`
`
`MQEmwET/L QEHEE m6_o>\ \
`
`m .OE
`
`10:26
`
`2N
`
`$55 $15
`
`
`
`55E 20563
`
`
`
`QEUEE 52x05;
`
`wmwmiowmnw oh
`
`PETITIONER APPLE INC. EX. 1006-4
`
`
`
`US. Patent
`
`Feb. 3, 2009
`
`Sheet 4 0f 16
`
`US 7,486,684 B2
`
`
`
`. Ca 10:26
`
`565
`
`2: 555 N8 N2 5x05 9:
`
`
`
`vEOEwz mmOQ
`
`2N
`
`v .QE
`
`
`
`
`
`
`20569 vEQsEz wmw9>o§ wosmww Z9209
`
`mwmiowmpw mwmiuwmnw
`
`.2: a mi
`
`PETITIONER APPLE INC. EX. 1006-5
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61f05LI.6ehS
`
`US 7,486,684 B2
`
`
`
`mam:u_OBoom
`
`I0.:>>w
`tom
`
`C)|E)O"| SNISSEOOEH
`
`zofiomzzoo
`
`N8
`
`zocomzzoo
`
`Sm
`
`zofiomzzoo
`
`PETITIONER APPLE INC. EX. 1006-6
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 6 of 16
`
`US 7,486,684 B2
`
`xmozcmzmaw
`
`
`
`n__o>ovm
`
`zofiomzzoo
`
`__
`
`_
`
`Ev_o<n_9:oFmmmSom
`fl<uwmmm8<¢__mummmmn_Q<n__o_,N::mzo_._n_n=_InE>>m
`
`
`
`mme>oEmosmwm
`
`
`
`7moI~Im_m_H_.o.._I<m%m|oI:II
`
`
`
`2:mmm_sm_Emmzopmso
`
`PETITIONER APPLE INC. EX. 1006-7
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 7 0f 16
`
`US 7,486,684 B2
`
`PETITIONER APPLE INC. EX. 1006-8
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 8 of 16
`
`US 7,486,684 B2
`
`_________________________
`
`_______
`
`_.mmmEo<n=
`
`
`
`N8mm>mm_w:o:>>m-Eom
`
`
`
`I11oMmm_m._m_,q._InuL
`
`mmmmom
`
`IummwmS<n:
`
`:5mzoxmn__
`
`{M
`
`II
`
`
`_:o8mm_w__>m_mn_4__Iammm_wn_m
`
`
`
`E2052020_._.<z_._.mm_n__.._.wmm_m_oo<n:mmmmmm_Sm“
`____.___:o:>>m_______
`mmmmom_Eogmx
`
`Ev_o<n_x_o<m-wz_m
`
`___
`
`__________
`
`Sm_2o_Bmzzoo_
`
`zo_Bm1zoo
`
`9.:
`
`PETITIONER APPLE INC. EX. 1006-9
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 9 of 16
`
`US 7,486,684 B2
`
`/5”.
`
`Smm_zo:n_n=
`
`_
`
`___
`
`_
`
`_98
`
`
`
`own:o:>>m-Eom
`
`mmmmom
`
`_._$8_I_
`
`Onwwmmoa<a.FII|III||II|IIL
`
`am_zo_5m_zzoo_
`
`zo_5m_1zoo
`
`2.:
`
`l|nillv
`
`
`
`____
`
`
`_.commmm_§mmn_4__|IIIIv.o.mImw_Wn_w
`
`$20530zo:<z:mmo_u_ummm_moo<n__mmmmow_Emfl
`_“:o:>>m_______
`mmmmom_m:.os_mm
`
`.m:o<axo<m_-wz_m
`
`PETITIONER APPLE INC. EX. 1006-10
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61r1001LI.eehS
`
`US 7,486,684 B2
`
`
`
`
`
`zofiomzzoozofiomzzoozofiomzzoo
`
`3m8m
`
`
`
`
`
`mmmmom:wz<Emwmmoz
`
`
`
`
`
`._.m_v_O<n.Ev_o<n_._..u._v_0<n_
`
`
`
`oEo3oE_._o._._>>mIozsmIo.:>>w
`
`H.nmmmmoo<n:_.n_nmmmmoo<n:mummm_moo<n:
`
`2.O_n_
`
`
`
`xoE>w.Eom:oEsw-Eow_._o:>>m-Eom
`
`
`mmmmom$8:mz<m»#0mmm_mez_
`
`
`
`ommow...omm
`
`onmmmmoo<n:Euwmmmoo<n:ouwmmmao<n=
`
`
`
`
`
`oz:<z_2mmfiO._.oz:<z_w_moEOE“.
`
`
`
`mm>mmmxmn_-n__mm>mm_wXmn_-n__
`
`
`
`
`
`PETITIONER APPLE INC. EX. 1006-11
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 11 of 16
`
`US 7,486,684 B2
`
`___m_______
`
`_
`
`_
`
`_:o:>>m-Eom
`
`Fiiii..|oIumIwmmmP<In__1L
`
`W3cum
`
`
`
`zo_.6m_zzoozoFom_zzg_Vo
`
`_
`
`Sa
`
`.#______________
`
`
`
`n=o>o.vN_O3.
`
`xmozfimzmaw
`
`Sm
`
`mnmmmm_8<n__Em
`
`._.m_v_o<n_
`
`IU._._>>m
`
`
`
`mmo_>oEm_o_>mmm_<ummm_%o<a.
`
`
`
`
`
`
`
`
`
`_|IIIlm.®N|m_:&_%u_%mm:mmm_s_mEE20530
`
`PETITIONER APPLE INC. EX. 1006-12
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61r1021LI.eehS
`
`US 7,486,684 B2
`
`
`
`
`
`wmmmwm._._mz<m._.mmmmwz
`
`
`
`
`
`Ev_o<a._.mxO<n_._.mv_0<n.
`
`
`
`
`
`I0._._>>wI0._._>>wI0._._>>w
`
`Smcs.SN
`
`Immmmoo.n__
`
`.8
`
`mzoxaom_<0
`
`
`
`mzozaoz_.:<o
`
`<mmmmoa<n:
`
`2:
`
`
`
`zocomzzooowmzozomzzooowvzocomzzooovmzofiomzzoo
`
`
`
`
`
`
`
`mo_O>mo_O>wo_O>mo_o>
`
`
`
`
`
`
`
`
`
`._.m_v_o<n_520$.Ex9:.m_v_o<n_
`
`EmnFmEmEm
`
`mo:na:ma:mo:
`
`
`36:nozo_Bmm_n_m:n__>_<xm_z_Am_z_26:nozo_5m_m_o
`
`
`zo:<z:mwooz,“zo:<z:mmooz,“
`momaom2I2momsom2I2
`
`zoozazwmoo_-zn_>o_-zn_>zoozazmnmo
`
`
`zozo_Bm_m_oA3n_s_vG.”m__»,_n,_\_W,_AVzozocomma
`
`
`mwmx8<n__mmmm8<¢_mmm_mB<n=m,nmEo<n__
`
`
`
`w_m><._mm=so._m_m><._mm=so._Ea:Ego;mma:E33
`
`
`
`
`
`
`
`>mB:_om%>mB_”__om:m>m_nm:_om%>mB:_om%
`
`
`
`SNzozomzzoo9:.zozomzzooSNzocomzzooSNzo_5m_zzoo
`
`PETITIONER APPLE INC. EX. 1006-13
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61r1031LI.eehS
`
`US 7,486,684 B2
`
`
`
`Ea:mm>>o._
`
`wwm_moo<n__mwmm8<m_H
`HHH.Ev_o<n_Exoé
`
`m_o_O>mo_o>
`
`o_.zn_>$5:$39
`
`, c
`
`
`
`um:mm._.__>>zo:<._:wn_<ozm\\
`
`,S982EoésmExo<n_mmm_momm_:m
`
`owmEmmmmoo<n__
`
`
`
`m_zo_._n_25¢><>>m»<0._.Zmn_._<oo._m_zoIn_o2_.:<o
`
`
`
`
`
`
`
`5.
`
`>“Ezmo_z<o:o:>>m-EommI._.
`
`
`
`rj<0oz__>_ooz_mom
`
`:o:>>m-Eom
`
`
`
`><>>m:<omo“.;_<0O._
`
`_.._o._._>>m.._h_Om
`
`
`
`
`
`20¢”.».wm<4zn_>m=._._.
`
`
`
`mmmsszom._<_omi...
`
`w.mm_o_>omn_
`
`v_mo2c.mzn:
`
`m_o_>mmm
`
`z<._
`
`PETITIONER APPLE INC. EX. 1006-14
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61f041LI.6ehS
`
`US 7,486,684 B2
`
`>mmm:.._n_n_<n:
`
`
`
`Nmmmaommam_.mmm_m_.nnu.%mDw
`
`so
`
`omm
`
`.205mwm_moo<n__s_oEmmm_mon_<n__
`
`
`
`Sm:m_Nmm_m_momm:wcum:9_.mmmiommsm
`
`mmmmmmmmm_mmz_
`
`
`
`_._oEsm-Eom:o:>>m-Eow
`
`
`
`mzozaom_j<o_.mmmmon_<n:mzozaoz_j<o
`
`
`Ev_o<n_.m_v_o<n_
`:oE>mNo:xozsm
`
`
`
`
`wmmmomm...“,_>.\,~n__m$...7.u_._mmmmwz_
`
`
`
`xmoafimzn:Ew.mmo_>oEm_o_>mm_mSN
`
`<mmm_moo<n:
`
`
`
`Nmmm_momm:mmo“.mm_”Ezmo_rmm_m_momm:mmommm::zmn__
`
`
`
`mi,.0_n_
`
`
`
`
`
`
`
`zn_>_.:._>>Ev_o<n.m_o_o>zn_>I._._>>m_xo<n_m_o_o>
`
`
`
`
`
`
`
`PETITIONER APPLE INC. EX. 1006-15
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61r10514|.eehS
`
`US 7,486,684 B2
`
`
`
`_20w_.._mmmmn_o<n:
`
`
` :o_._>>w-Eom\wmmmom\\\mum:m.NmmmiommnmSm:m.m_o<n_mEm:m__.mmmiowmsm
`_>_oEmmmmoo<n:m_mma_>omn_m_o_>mm_m_>_oEmmm_moo<n:
`
`
`
`
`
`
`
`
`
`r
`
`mmmfimmam::
`
`mzoza8.35_.mmmmoo<n:\mzoxmoz_j<o
`
`
`
`w.mmo_>oE<w$moo<n:>wmmman_<n:mo_>mm_mmmmiommzw
`
`2525Nmm_m__momm:mFmmmaommam
`SE.32
`
`
`
`ID.:>>wExo<n_Io._._>>mExo<n_mmmommmmmoz_
`
`Ebo_.N
`
`I._._>>Exoimo_o>
`
`
`
`mm_u.Fzmo_zn_>4<_omn_m
`
`PETITIONER APPLE INC. EX. 1006-16
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`61r1061AI.eehS
`
`US 7,486,684 B2
`
`
`
`mzoxawz_j<o
`
`Em
`
`
`
`_.mmm_mon_<n:IOwmmmoo<n:mzo_._n_oz_j<o
`
`mwmm_moo<n:m_o_>mmm
`mmmaommammmmmfimmsm
`
`
`
`
`
`mmmaommzmmmmiowmaw..
`
`Z<._Z<:_.,..
`
`
`
`@mmoSoma<mwmmOQ<1_
`
`
`
`wmmmwmmwmmoz_
`
`omm
`
`
`
`mmmmomommmmmmoz_
`
`
`
`
`
`IO:>>w._.m_v_o<n__._o:>>mE205
`
`o_.mo«N
`
`3.3S
`
`
`
`m_<n_mmm_moo<n:
`
`PETITIONER APPLE INC. EX. 1006-17
`
`
`
`US 7,486,684 B2
`
`1
`METHOD AND APPARATUS FOR
`ESTABLISHMENT AND MANAGEMENT OF
`VOICE-OVER IP VIRTUAL PRIVATE
`NETWORKS IN IP-BASED
`COMMUNICATION SYSTEMS
`
`FIELD OF THE INVENTION
`
`The invention relates to the ?eld of communications sys
`tems and more speci?cally 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.
`
`DESCRIPTION OF THE BACKGROUND ART
`
`2
`alternative is similar to the “SoftWare De?ned 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 e?icient to connect the IP PBXs
`through an IP netWork, Without converting the voice tra?ic 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 traf?c in anVoIP 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 identi?er in the neW communication,
`passing the neW communication to the terminating point and
`removing the VPN identi?er from the neW communication.
`The VPN identi?er is an extra ?eld (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
`
`20
`
`25
`
`30
`
`35
`
`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 ofa number ofIP 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 tra?ic 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 tra?ic 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
`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
`tra?ic 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 bene?t. In the TDM environment, this
`
`40
`
`50
`
`55
`
`60
`
`65
`
`PETITIONER APPLE INC. EX. 1006-18
`
`
`
`US 7,486,684 B2
`
`3
`er’ s VoIP-VPN to a terminating point of another subscriber’ s
`VoIP-VPN, modifying the VPN identi?er 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 tra?ic 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 bene?t 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 ?rst.
`Additionally, the same architecture also applies to other voice
`over packet technologies such as ATM With slight modi?ca
`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 of?ce 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 1 05 is connected to
`a special media gateWay 210 at the SP’s central of?ce. 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 tra?ic 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 (eg
`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 of?ce 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 identi?er 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 or as a single unit. For simplicity, in the
`folloWing descriptions, the soft-sWitch represents the entire
`
`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
`con?guration;
`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 classi?er 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 How diagram of forWard signaling of a call
`in the ingress soft sWitch of the system;
`FIG. 7 depicts a How diagram of forWard signaling of a call
`in the transit netWork;
`FIG. 8 depicts a How diagram of forWard signaling of a call
`in the egress soft sWitch;
`FIG. 9 depicts a How diagram of return signaling of a call
`in the egress soft sWitch;
`FIG. 10 depicts a How diagram of return signaling of a call
`in the transit netWork;
`FIG. 11 depicts a How 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 con?guration of a call from the VPN to
`the Public SWitched Telephone Network in one embodiment
`of the subject invention;
`FIG. 14a depicts a con?guration of a call from a ?rst VPN
`to a second VPN in one embodiment of the subject invention;
`FIG. 14b depicts a con?guration of a call from a ?rst VPN
`40
`to a second VPN in a second embodiment of the subject
`invention; and
`FIG. 15 depicts a con?guration for a call betWeen tWo
`locations on the same VPN Where address translation is used
`to transfer tra?ic 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 ?gures.
`
`20
`
`25
`
`30
`
`35
`
`45
`
`DETAILED DESCRIPTION
`
`The subject invention speci?es 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.l64 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
`
`PETITIONER APPLE INC. EX. 1006-19
`
`
`
`US 7,486,684 B2
`
`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 ?rst 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 classi?cation. FIG. 3 depicts an abbre
`viated vieW of the communication system 200 for the pur
`poses of focusing on packet classi?cation. In most cases,
`packet classi?cation is performed in the packet sWitch 210.
`Both data and voice traf?c is sent from the Customer Premise
`105 to the packet sWitch 210. The packet sWitch 210 classi?es
`the packets and forWards all VoIP-VPN voice packets to a
`VoIP netWork (and vice versa). TheVoIP 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 classi?er 302 is exter
`nal to the packet sWitch 210. One or more tunnels 300x are
`established betWeen packet classi?er 302 and the packet
`sWitch 210. The packet sWitch 302 forWards all voice tra?ic to
`the packet sWitch 210 through these tunnels 300x. In short,
`packet classi?cation is a function of a logical module Which
`can be external or internal to the packet sWitch 210.
`In one embodiment of this classi?er 302, each access inter
`face has an associated table Whose entries consist of destina
`tion and origination IP-address/U DP 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 traf?c.
`As the number of the active phones rise even during busy
`hours, the classi?cation 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 traf?c can be assigned a diffServ
`(RFC 2474) code point (DSCP) and the classi?cation may
`key on this code point. In this example, the classi?cation 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 classi?cation process is performed at the ?rst point of
`entry to the SP’s network. If the ?rst point of entry is the
`soft- sWitch 220, information to build the classi?cation 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 ?rst point of entry is another device,
`that device needs to support the classi?cation module and to
`be under soft-switch control. VoIP-VPN traf?c 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 classi?er 302 alloWs the same architec
`ture as the one at the SP central of?ce and is under the control
`of the IP-PBX server. After classi?cation, the subscriber can
`put the VoIP-VPN traf?c in tunnels (for example, a dedicated
`layer 2 tunnel) and transfer the packets to the SP. Certain
`
`5
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`advantages of putting the VoIP-VPN traf?c on separate layer
`2 tunnels include: (1) the ability to engineer the tunnels to the
`desired QoS level; (2) an ease in security administration as the
`traf?c is separated and different policies can be applied to the
`VoIP-VPN tra?ic; 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 of?ces are connected to
`each other through a netWork 310 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 tra?ic volume betWeen tWo packet
`sWitches Warrants such a connection. More speci?cally, 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
`speci?cation 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 speci?cations to support the different types of
`gateWays. These extensions are referred to as “packages”.
`The packet sWitch 210 can be considered as a speci?c type of
`gateWay Where all the terminations are ephemeral (non-per
`manent). This folloWing description speci?es 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 speci?cation. 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 traf?c is depicted in FIG. 5. The packet sWitch 210 is
`provided With a plurality of layer-l (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
`
`PETITIONER APPLE INC. EX. 1006-20
`
`
`
`US 7,486,684 B2
`
`,
`
`7
`number of active calls over a specific connection. Calls are
`identified as call terminations within packet switch 210.
`W'hen the soft-switch 220 needs to establish a cross-con-
`nect (e.g. connect a VolP 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;
`add appropriate ephemeral terminations to tl1e
`context; and (3) cross-comiect tl1e 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 ir1 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 Terrninations.
`The Connection End-Point parameter identifies the connec-
`tion that the packets come fror11 (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 ofthe connection.
`Its structure may depend on the implementation of the packet
`switch (e.g., slot ntnnber and port mnnber). For simplicity, the
`intcrfacc_numbcr ofthe Interface SNIVIP MIB can be used to
`identify the interface. This assumes the existence ofthe Inter-
`face_MIB. Layer 2 identifier(s) identify layer 2 of the con-
`r1ectio11s, both tl1e “type” and tie corresponding “identifica-
`tion (ID)” field. This field will have two sub-field