`
`(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. 1003-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. 1003-2
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 2 of 16
`
`US 7,486,684 B2
`
`xmozcmzmamI_IIIIII%>_II_mm_o<wmm2
`
`oz:<ze_m__
`
`m_T_oEm_>_
`
`
`
`wz:<zw_wSm
`
`mm_:o:>>m-.Eom_\\omm__$15OhTxx:o:>>m.Eom""mmo<mmms_rIIIIIIIIIIIIIIIIIIFuuuuuuuuuuuuuuuuuuuuuIL
`
`v_m_o>>Ezn=
`
`
`
`mmo_>mm_m<._.<Q
`
`xmozfimzmnm
`
`--wmN.m%.,.,...%_.z.w%
`mm_o_>omn_wo_>mm_w"
`
`
`
`mofmflz;
`
`SE28.
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-3
`
`PETITIONER APPLE INC. EX. 1003-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. 1003-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. 1003-5
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 5 of 16
`
`US 7,486,684 B2
`
`omm
`
`IO.:>>m-._.u_Om
`
`
`
`mam:..._Omaoow
`
`Sm
`
`m..U_n_
`
`C)|90"| E)N|SS3C)0Hd
`
`ZOFOMZZOO
`
`N8
`
`zocbmzzoo
`
`Sm
`
`ZOFOMZZOU
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-6
`
`PETITIONER APPLE INC. EX. 1003-6
`
`
`
`
`
`
`U.S. Patent
`
`40/
`
`2B4006,600
`
`mosmwm._mHw$Eo<n:SN“_:o:>>w__»mxo<m_mEm__.mxmozcmzmsmMn__o>_SN_m_zocomzzoo_s_____Em_w__m__3,__m__F_
`7IIIIIIII|III.Its_18~m_oEo
`._<Ezm_o1“U_mmQ>oE
` __uN5omm:o:>>m-Eom__oummmmoo<n=__|IIIIIIIIIIIII.L
`
`
` _IlI‘'III'IIIIII’InI.I__we.,m_m_s_wEmmzohmso_u<Hmwmm8<¢_“_::mzoxmn=_.oi_WmmSomH)__9.470NS_WSmW_momSm__________Smc:mm_>mmm“___moo______|
`IIII||III'I‘IIII|L
`
`mi
`
`
`
`o.O_u_
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-7
`
`PETITIONER APPLE INC. EX. 1003-7
`
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 7 0f 16
`
`US 7,486,684 B2
`
`PETITIONER APPLE INC. EX. 1003-8
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 8 of 16
`
`US 7,486,684 B2
`
`_
`
`
`
`
`
` _hwmo“3%“_ 'HM_I‘iii*_,m8m8<n=“«mm_omm#E_mowmm>mmm__:o:>>m-Eom____mmmmwm____-_r::::::::::::::::Lr-»»o»...aH.w&n_M_<»._._---.._
`
`____HH_
`
`_)W_Q_zo:fimzzoo_08:_”#zo_5m1zoo
`
`ITIV
`
`Sm
`
`
`_w8»mm_w_sm_E4__7..III¢.mmImm_wn_m4.<m_..,_.flo.fl_E20530
`
`
`
`
`
`
` zo:<z_Bmo__mmmmem____H.-mmm_m8<n:__Iummwm8<n=__:oo»__m>m_“somzoxa.__fl_Ev_o<n_x"o<m_-wz_m
`
`w.O_n_
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-9
`
`PETITIONER APPLE INC. EX. 1003-9
`
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 9 of 16
`
`US 7,486,684 B2
`
`
`
`_____Nmw__$8_3________«mo_wmo_H__I_%Nowmw>mmm_vmo_ommI0._._>>m
`tom___-H3__mmmmem.__**__onwwm_moo<¢___.
`IIIIIIIIIIIIIIIII._VIIIIIIIIIIIIIL
`
`_zo:fimzzoo_2.:___zozomwzoo zo:<z:mmo%ku_ummmmon_<n:mmmmom#____.som_zOIn_n=__._.mv_O<n_v__O<m-0Z_mj3_mwmmwm_w._.O_>_mN__)“.Hv
`
`
` SN3;wowmmm_s_mmnL“Ivowmo_n_n_o._<m._.zm_oJ_3E20520
`
`
`
`aGE
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘IO
`
`PETITIONER APPLE INC. EX. 1003-10
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 10 of 16
`
`US 7,486,684 B2
`
`_,_o:>>m.Eom
`
`om...
`
`mmmmom
`
`95
`
`zo:>>m-Eom
`
`:mz<E
`
`emu
`
`N3
`
`,_._o:>>m.Eom
`
`omm
`
`mmm_mwz_
`
`onmmmmoo<n:
`
`Eummmmoo<n:
`
`oummmmn_o<n:
`
`
`
`
`
`0z_._.<z__2m_m._.O._.oz:<z_w_mo20¢“.
`
`
`
`mm>mmmXm_n_-n__mm>mm_mXmn_-n=
`
`
`
`
`
`
`
`
`
`zofiomzzoozofiomzzoozofiomzzoo
`
`Sm
`
`OE
`
`mmmmom
`
`Exo<n_
`
`_._o._._>>m
`
`Sm
`
`:wz<E
`
`Ev_o<n_
`
`_._O._._>>w
`
`Ev
`
`mmmmoz.
`
`._.mv_O<n_
`
`_._U.:>>w
`
`o_.N
`
`u.ummmmoo<n:
`
`_.Qnmmmmonzn:
`
`mummmmoo<n:
`
`2.O_u_
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I1
`
`PETITIONER APPLE INC. EX. 1003-11
`
`
`
`
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 11 of 16
`
`US 7,486,684 B2
`
`.35
`
`#_______
`
`n:o>
`
`xmozfimzmnm
`
`Sm
`
`ZOFOMZZOO
`
`own
`
`zoTom_zzn_.o
`
`_o3_
`
`mmzopmao_mNmm#_8<2SN___:Wwzo_._._n=_Iossm__5._._.mv_O<n___KMHDOM___
`_||IIII''IIIlIII||_.1III|IIII|I|I||IInInJ_mowm_o_&o4<E.zmo__wemmm__>m_E
`
`
`_._..O_n_
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I2
`
`PETITIONER APPLE INC. EX. 1003-12
`
`
`
`
`
`
`S.U
`
`9
`
`2
`
`2B48
`
`zocomzzo
`
`.:8._>>mMExoiExoiExo<n_Pwmmmom:mz<Emmmmwz_
`
`
`
`
`
`:o_._>>mtoEmzo_5mzzooO3zocomzzooSmzo:om_zzoom_._o:>>m
`
`
`.N—OE
`
`/....\8m9;SN9:\
`
`F‘
`
`
`mImmmw_Am%.n__<mmmm8<n:
`
`3,2:4.mzoxmom_<omzoxaoz_j<o
`
`
`
`
`
`mo_o>mo_o>mo_o>mo_o>
`
`
`.1.QODHH.5:
`
`e32mEHHEm_v_o<n_mv_o<n_BEEBEE
`
`mmmm8<n:6zo:<z:mmooz,“zo:<z:maoz,“1momaom2I2momsom21.2Mmmm~_8<n:mmmm8<2mmmmn_o<n__
`
`
`
`
`
`25:nozo_5#__om:s_<xm_z_A53z_S6:mozo_5mx_o
`
`zoozazmnmo9-2%9-2%zoozazmnmo
`
`zozofimmaAmag3mung.zozocomma
`
`
`
`MSE83cum,2%WSNzo_SmzzooOs.zozomzzooSN.SNzozomzzooSNzozomzzoo
`SEB:_om_%EB_“__om_%E828%EB_”__om%UEa:E39Ea:$.53$5:$29m_m><._E39
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I3
`
`PETITIONER APPLE INC. EX. 1003-13
`
`
`
`
`U.S. Patent
`
`3
`
`7:
`
`2B4006:6
`
`
`
`z<._Mv_mo>>.m_zn:
`H,Em:mmj_>>zo:<.Swn_<ozm\m/\y>\S/\
`
`mzozm023.203,O9.
`,SN\Emmmmoo<n__,\m8282Eozsmm§o<n_\mmm_m%.mm_:wMm_zo_._n_25¢><>>m»<oEmaL._<oo._
`
`m.mmo_>omn_
`
`
`
`>u=._.ZmO_z<o_._o:>>m-Eomm_,:
`
`s_oEdmiZ&>mi
`
`
`
`mmmsszom._<_owt.mo_>mm_m
`
`.<
`
`
`
`.3oez_s_ooz_mom2.2IcumIoE>m.Eom
`
`><>>E<omo“.com.209.
`:o:>>m-EomweOE
`
`
`
`REb:~m_>>o._
`
`W829.2%E52E33
`
`mmm_mn_o<n__mmmmoo<m_HH6HHHEvaiE550m_o_O>m_o_o>
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I4
`
`PETITIONER APPLE INC. EX. 1003-14
`
`
`
`
`U.S. Patent
`
`47,SU
`
`2BM
`
`
`
`_20mEmwm_moo<n__
`
`
`
`ZONEmmm_moo<n=
`
`mum:m_Nmmmaommam
`
`omm:m_Vmmmaowmsm
`
`cum\/omm
`
`
`
`mmmmommmmmoz_
`
`
`9<mmNwWmwww%.m_.,_W.%_%%m<.m_
`
`
`
`
`
`
`3,so2:wmzoxao.u:._<o_.mmmxo.o<n:ommmmoo<n__mzoxmoz_j<o
`
`6,.%mi®_n_
`
`25Nmmmaommpm
`
`
`
`ammmmmomEz-mEz_mmmmoz
`
`Zn_>_¢_>>Exofim_o_o>2%1:2,m§o<n_m_o_o>mv_mo>>Ezn:
`
`
`
`
`m_o_>mm_m2NM:oE>mNo::o:>>w
`oinm.mmo_>oE
`
`
`
`
`Nmm_m_momm5mmo”.mmmczme_.~m_m_momm:wmommm_u_:zm_o_
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I5
`
`PETITIONER APPLE INC. EX. 1003-15
`
`
`
`
`U.S. Patent
`
`Feb. 3, 2009
`
`Sheet 15 of 16
`
`US 7,486,684 B2
`
`s_oEmmm_moo<n:
`
`
`
`
`
`
`
`
`/w.mm9>omn_\<wmmmoo<n:>wwmm8<n:mo_>mmmmmmiommnw
`
`
`
` wmmmom\,\own/\omm/\,\,\,\/Em:m_Nmmmiowmnwcum:9m_o<n_mEm:m__mm_m_momm:m
`_>_oEmmmmoo<0:m.En__>omn_mo_>mmms_oEmmm_moo<n:
`_._o_._>>w-Eom\,:ow_%_mm%_wm
`
`W.mm_N_mfivw©mDw\/—.o—.F\/mzozaom_.:<oammmmoo<n:\/ommmmo.o<2mzoxmoz_j<o
`
`2525Nmmmzommam_Emaommam
`
`3:mmmowmmmmoz$2
`
`
`
`:oE>w55$._._o:>>mExofi
`
`SmSN
`
`
`
`1:2,Exoim_o_o>
`
`
`
`
`
`
`
`mm_n_:zmo_zn_>..<_omEm
`
`3.3mm
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I6
`
`PETITIONER APPLE INC. EX. 1003-16
`
`
`
`
`U.S. Patent
`
`1f061
`
`7SU
`
`2B4006M
`
`mSmEm
`
`
`
`«A:o:>>m._.mv_O<n_IU._._>>w._.m_v_O<n_
`
`
`
`wmmmwmwmmmoz_
`
`_.0
`
`
`
` Z41.Z<:_MmmmiommsmmmmiowmawWmmmm_mon_<n:m.mw__>_%Mm<mmmmoo<n__mmmmwfimmsw
`mmmfiwewmsm
`
`
`
`mmmmomommownmwmmoz
`
`4,m_‘GE
`
`Es2.88.3
`
`
`
`m=<n_mmm_moo<n:
`
`PETITIONER APPLE INC.
`
`EX. ‘I003-‘I7
`
`PETITIONER APPLE INC. EX. 1003-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. 1003-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. 1003-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. 1003-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.
`When the soft-switch 220 needs to establish a cross-con-
`
`8
`intervals. In one embodiment ofthis invention, the setting and
`retrieval of this information is executed through the H.248
`vertical interface.
`
`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 plura