5/10/12

Packet Telephony Network Drivers

Packet Telephony Network Drivers

The pre vious se ction discusse d political drive rs for com pe tition in the PSTN. This se ction e x plains why a carrie r m ight choose to de ve lop a pack e t te le phony ne twork in lie u of a traditional circuit-switching ne twork . The inte gration of D/V/V is m ore than just a change in infrastructure . D/V/V inte gration also e nable s ne w fe ature s to be de ve lope d m ore quick ly and ope ns up application de ve lopm e nt to thousands of Inde pe nde nt Software Ve ndors (ISVs). You can com pare this inte gration of D/V/V to the change from m ainfram e com pute rs, for which ve ry fe w ve ndors de ve lope d applications, to clie nt/se rve rs, for which m ultiple ve ndors de ve lope d applications for distribute d syste m s. Figure 1-12 shows how the circuit-switching m ode l is bre ak ing into a ne w m ode l by which ope n standards e x ist be twe e n all thre e laye rs. A pack e t infrastructure will carry the actual voice (m e dia), the call-control laye r will be se parate from the m e dia laye r, and ope n APIs (Application Program m ing Inte rface s) will e nable ne w se rvice s to be cre ate d by ISVs.

Figure 1-12. Circuit Switching Versus Packet Switching

[View full size image]

Figure 1-12 is an ove r-sim plification of the change s that are actually happe ning. To furthe r discuss the se change s, you ne e d to tak e a close r look at e ach of the thre e laye rs.

Standards-Based Packet Infrastructure Layer

The pack e t infrastructure re place s the circuit-switching infrastructure in this ne w m ode l. This infrastructure m ost lik e ly will be IP, although this m ode l also work s if ATM is the unde rlying transport and IP ride s across the top. IP is so attractive as the pack e t infrastructure be cause of its ubiquitous nature and the fact that it is the de facto application inte rface . This m e ans that software applications running ove r IP do not have to be k nown. IP sim ply transports the data e nd to e nd, with no re al inte re st in the payload.

Note
To provide the prope r prioritization on a congested IP ne twork , the IP ne twork m ust have som e k nowle dge of the applications.

R e al-tim e Transport Protocol (R TP) is utilize d in addition to a Use r Datagram Protocol (UDP)/IP he ade r to provide timestamping. R TP runs atop UDP and IP and is com m only note d as R TP/UDP/ IP. R TP is curre ntly the corne rstone for carrying re al-tim e traffic across IP ne twork s. (Microsoft Ne tm e e ting, for instance , utilize s R TP to carry audio and vide o com m unications.) To date , all VoIP signaling protocols utilize R TP/UDP/IP as the ir transport m e chanism for voice traffic.
fengnet.com/book/voip/ch01lev1sec5.html 1/6

5/10/12

Packet Telephony Network Drivers

O fte n, R TP pack e t flows are k nown as RTP streams. This nom e nclature is use d to de scribe the audio path. In IP ne twork s, it is com m on and norm al for pack e t loss to occur. In fact, Transm ission C ontrol Protocol/Inte rne t Protocol (TC P/IP) was built to utilize pack e t loss as a m e ans of controlling the flow of pack e ts. In TC P/IP, if a pack e t is lost, it is re transm itte d. In m ost re al-tim e applications, re transm ission of a pack e t is worse than re ce iving a pack e t due to the tim e -se nsitive nature of the inform ation. The ITU-T re com m e nds a one -way de lay of no m ore than 150 m s. In a C isco VoIP ne twork , the unidire ctional de lay m ight be 120 m s (curre ntly, 65 m s to 85 m s of that 120-m s de lay is de rive d from two C isco VoIP gate ways whe n using G.729). If the re ce iving station m ust re que st that a pack e t be re -transm itte d, the de lay will be too large , and large gaps and bre ak s in the conve rsation will occur.

Note
The R TP stre am is also ofte n re fe rre d to as the media stream. The re fore , you can use IP in conjunction with UDP and R TP to re place a traditional 64-k bps voice circuit.

R TP has a fie ld that stam ps the e x act tim e the pack e t was se nt (in re lation to the e ntire R TP stre am ). This inform ation is k nown as RTP timestamps and is use d by the de vice te rm inating/re ce iving the audio flow. The re ce iving de vice use s the R TP tim e stam ps to de te rm ine whe n a pack e t was e x pe cte d, whe the r the pack e t was in orde r, and whe the r it was re ce ive d whe n e x pe cte d. All this inform ation he lps the re ce iving station de te rm ine how to tune its own se ttings to m ask any pote ntial ne twork proble m s such as de lay, jitte r, and pack e t loss.

Note
Jitter is the variation of inte rpack e t arrival tim e , or the diffe re nce be twe e n whe n a pack e t is suppose d to be re ce ive d and whe n it is actually re ce ive d.

O ne of the m ain be ne fits of IP is the fact that prope rly built IP ne twork s are self-healing. This m e ans that be cause dynam ic routing protocols are use d and m ultiple possible de stinations e x ist, a ne twork can re -conve rge base d upon the be st route . It also m e ans that it is possible for your voice (pack e tize d in IP) to tak e m ultiple paths to the sam e de stination. C urre ntly you cannot nail up a single path be twe e n two de stinations. Each individual pack e t tak e s the be st path be twe e n se nde r and re ce ive r. The fact that the pack e t laye r is base d upon ope n standards e nable s m ultiple ve ndors to provide solutions that are inte rope rable . The se ope n standards e nable incre ase d com pe tition at this pack e t laye r. The ITU-T, Inte rne t Engine e ring Task Force (IETF), Europe an Te le com m unication Standards Institute (ETSI), and EIA-TIA are only a fe w of the standards bodie s you m ight be fam iliar with. O ne k e y com pone nt of having a standards-base d pack e t infrastructure is the ability to have ope n standards to laye rs at the call-control laye r. R e fe rring to Figure 1-12, the se ope n standards are provide d by protocols such as SIP, H.323, SGC P, MGC P, MEGAC O , and so on, which have ope n de fine d inte rface s and are wide ly de ploye d into the pack e t infrastructure . O ne of the jobs of the call-control protocol is to te ll the R TP stre am s whe re to te rm inate and whe re to be gin. C all-control accom plishe s this task by translating be twe e n IP addre sse s and phone num be ring plans.

Open Call-Control Layer

C all-control, in a nutshe ll, is the proce ss of m ak ing a routing de cision about whe re a call ne e ds to go and som e how m ak ing the call happe n. In the PSTN today, the se de cisions are carrie d out by SS7 and are m ade by Se rvice C ontrol Points (SC Ps). C hapte r 7, "VoIP: An In-De pth Analysis," discusse s how the diffe re nt VoIP protocols work and how the y solve diffe re nt ne twork de sign issue s. In this ne w m ode l of se parating the be are rs (R TP stre am s) from the call-control laye r and se parating the call-control laye r from the se rvice s, it is ne ce ssary to m ak e sure that standards-base d protocols are use d. Data ne twork ing is unique in the fact that m ultiple protocols can co-e x ist in a ne twork and you can tailor the m to the particular ne e ds of the ne twork . Many diffe re nt IP routing protocols e x ist, for e x am ple , and e ach is spe cifically de signe d for a ce rtain type of ne twork . Som e of the se include the R oute r Inform ation Protocol (R IP), Inte rior Gate way R outing Protocol (IGR P), Enhance d Inte rior Gate way R outing Protocol (EIGR P), Inte rm e diary Syste m to Inte rm e diary Syste m (IS-IS), O pe n Shorte st Path First (O SPF), and Borde r Gate way Protocol (BGP). Each protocol solve s a sim ilar proble m routing update s. Each routing proble m is slightly diffe re nt, howe ve r, and re quire s a diffe re nt tool. In this case , the tool is a routing protocol, which solve s e ach proble m . You can say the sam e of VoIP call-control protocols. The y all solve a sim ilar proble m phone num be ring to IP addre ss translation; howe ve r, the y m ight all be use d for slightly diffe re nt purpose s.
fengnet.com/book/voip/ch01lev1sec5.html 2/6

5/10/12

Packet Telephony Network Drivers

Many VoIP call-control protocols are be ing de ve lope d, m ost notably SIP, which continue s to tak e the IP com m unications world by storm . For the last fe w ye ars, SIP-base d archite cture s offe re d m ore inte llige nce to the e ndpoints and have grown substantially in offe ring VoIP se rvice s. The y have le d to change s in the ne twork that assum e d ce ntralize d call control using se ssion controlle rs and softswitches that use othe r protocols lik e H.323, MGC P, and H.248/MEGAC O . Each protocol was de ve lope d to fix a ce rtain proble m and se rve a particular purpose . For the short te rm , at le ast, m any protocols will be use d, and the re will be a hybrid ne twork for a while addre ssing the ne e ds of diffe re nt ne twork topologie s.

VoIP Call-Control Protocols

As of this writing, the m ain VoIP call-control protocols are SIP, H.323, MGC P, and H.248/MEGAC O . Anothe r ve ry popular e x te nsion of VoIP te le phony is the Pe e r to Pe e r (P2P) VoIP IP Te le phony Mode l as use d by Sk ype ; howe ve r, it is still not e ndorse d as a standard. The curre nt standards on protocols are de fine d as follows: H.323 is the ITU-T re com m e ndation with the large st installe d base , sim ply be cause it has be e n around the longe st and no othe r protocol choice s e x iste d be fore H.323. C hapte r 11, "H.323," discusse s this protocol in de tail. MGC P has its roots in e arlie r protocols such as SGC P, and IPDC was de ve lope d starting in 1998 to re duce the cost of e ndpoints (gate ways) by having the inte llige nt call-control occur in a ce ntralize d platform (or gate way controlle r). C hapte r 13, "Gate way C ontrol Protocols," cove rs this in m ore de tail. ITU's H.248, also k nown as the MEGAC O protocol, is the inte rnational standard for m e dia gate way control. It is a standard publishe d jointly by the ITU and the IETF. It is prim arily use d to se parate the call control logic from the m e dia proce ssing logic in a gate way. The de vice that handle s the call control function is re fe rre d to as a Me dia Gate way C ontrolle r (MGC ) and the de vice that handle s the m e dia is re fe rre d to as a Me dia Gate way. SIP is be ing de ve lope d as a m e dia-base d protocol that will e nable e nd de vice s (e ndpoints or gate ways) to be m ore inte llige nt, and e nable e nhance d se rvice s down at the call-control laye r. C hapte r 12, "Se ssion Initiation Protocol," cove rs SIP in de tail.

Note
Pe e r to Pe e r (P2P) VoIP is still in its infancy and is active ly prom ote d as anothe r te chnology option for VoIP. P2P ne twork ing is the utilization of the re lative ly powe rful com pute rs (pe rsonal com pute rs) that e x ist at the e dge of the Inte rne t for m ore than just clie nt-base d com puting task s. The m ode rn PC has a ve ry powe rful archite cture that can pe rform VoIP and audio/vide o confe re ncing be side s pe rform ing com m on com puting task s such as e -m ail and W e b browsing. The m ode rn PC can e asily act as both a clie nt and a se rve r (a pe e r) for m any type s of applications. Microsoft and Sk ype are two ve ndors that are te sting and de ploying VoIP as a se rvice ove r a P2P ne twork .

To brie fly e x plain the various diffe re nce s be twe e n the se call-control protocols, le t's tak e a look at how the y signal e ndpoints.

H.323
H.323 is an ITU-T re com m e ndation that spe cifie s how m ultim e dia traffic is carrie d ove r pack e t ne twork s. H.323 utilize s e x isting standards (Q .931, for e x am ple ) to accom plish its goals. H.323 is a rathe r com ple x protocol that was not cre ate d for sim ple de ve lopm e nt of applications. R athe r, it was cre ate d to e nable m ultim e dia applications to run ove r "unre liable " data ne twork s. Voice traffic is only one of the applications for H.323. Most of the initial work in this are a focuse d on m ultim e dia applications, with vide o and data-sharing a m ajor part of the protocol. Applications re quire significant work if the y are to be scalable with H.323; for e x am ple , to accom plish a call transfe r re quire s a se parate spe cification (H.450.2). SGC P and MGC P, on the othe r hand, can accom plish a call transfe r with a sim ple com m and, k nown as a m odify conne ction (MDC X), to the gate way or e ndpoint. This sim ple e x am ple re pre se nts the diffe re nt approache s built into the protocol de sign itse lfone tailore d to large de ploym e nt for sim ple applications (MGC P), and the othe r tailore d to m ore com plicate d applications but showing lim itations in its scalability (H.323). To furthe r de m onstrate the com ple x ity of H.323, Figure 1-13 shows a call-flow be twe e n two H.323 e ndpoints.

Figure 1-13. H.323 Call-Flow

fengnet.com/book/voip/ch01lev1sec5.html

3/6

5/10/12

Packet Telephony Network Drivers

Figure 1-13 illustrate s the m ost basic H.323 call-flow. In m ost case s, m ore ste ps are ne e de d be cause gate k e e pe rs are involve d. To be tte r e x plain Figure 1-13, le t's ste p through the call-flow: 1. Endpoint A se nds a se tup m e ssage to Endpoint B on TC P Port 1720. 2. Endpoint B re plie s to the se tup m e ssage with an ale rting m e ssage and a port num be r to start H.245 ne gotiation. 3. H.245 ne gotiation include s code c type s (G.729 and G.723.1), port num be rs for the R TP stre am s, and notification of othe r capabilitie s the e ndpoints have . 4. Logical channe ls for the UDP stre am are the n ne gotiate d, ope ne d, and ack nowle dge d. 5. Voice is the n carrie d ove r R TP stre am s. 6. R e al Tim e Transport C ontrol Protocol is use d to transm it inform ation about the R TP stre am to both e ndpoints. This call-flow is base d on H.323 v1. H.323 v2, howe ve r, e nable s H.245 ne gotiation to be tunne le d in the H.225 se tup m e ssage . This is k nown as fast-start, and it cuts down on the num be r of roundtrips re quire d to se t up an H.323 call. It doe s not, howe ve r, m ak e the protocol any le ss com ple x . More de taile d analysis of H.323 is found in C hapte r 10.

MGCP (Evolution from SGCP and IPDC)

SGC P and MGC P we re de ve lope d to e nable a ce ntral de vice , k nown as a Me dia Gate way C ontrolle r (MGC ) or softswitch, to control e ndpoints or Me dia Gate ways (MGs). You can de ve lop applications through the use of standard-base d APIs that inte rface with the MGC s and offe r additional functionality (such as call waiting and C LASS fe ature s) and applications. The C isco ve rsion of this te chnology is be tte r k nown in the fie ld as two unique products: C isco PGW 2200 and C isco BTS10200. C isco PGW 2200, the call age nt de scribe d he re , furthe r consists of m any diffe re nt e le m e nts such as C isco Me dia Gate way C ontrolle r (MGC ) software , C isco Signaling Link Te rm inals (SLT), LAN switch for IP inte rconne ctivity of C isco PGW 2200 e le m e nts, and so on. In this sce nario, the e ntire IP ne twork acts lik e one large virtual switch, with the PGW controlling all the MGs. Figure 1-14 shows how a typical ne twork de sign work s with a virtual switch running MGC P.

Figure 1-14. Cisco PGW2200: Packet Tandem

[View full size image]
fengnet.com/book/voip/ch01lev1sec5.html 4/6

5/10/12

Packet Telephony Network Drivers

Figure 1-14 also shows how the le gacy PSTN and e nte rprise ne twork s are conne cte d to gate ways or e ndpoints that e nable acce ss into the ne w pack e t ne twork . This pack e t gate way re ce ive s dire ction from the C all Age nt (PGW 2200), which can com m unicate with the SS7 ne twork and the IN and can te ll the gate ways or e ndpoints how and whe n to se t up the call. To unde rstand Figure 1-14 in gre ate r de tail, all the various com pone nts m ust be de scribe d. The e x isting PSTN/SS7 ne twork is conne cte d to the Switching Transfe r Point (STP), which also is conne cte d to the MGC or C all Age nt. This conne ction is whe re the signaling (SS7) link s te rm inate and is calle d the Signaling Link Te rm inal (SLT), as shown in the figure . The SLT provide s the SS7 inte rface for the PGW and form s an inte gral com pone nt of any MGC that provide s SS7 inte rface . The PSTN/SS7 ne twork is also conne cte d to an MG, which is a signal-le ss trunk that is ofte n k nown as an Inter-Machine Trunk or IMT. The MG is whe re the 64-k bps voice trunk s are conve rte d into pack e ts and place d onto the IP ne twork . The MGC s or C all Age nts (PGW 200, in this case ) also inte rcom m unicate . The re is no com m on protocol m andate d by standards bodie s to achie ve this, howe ve r. Base d on the curre nt state of the industry, howe ve r, it appe ars that a variant of SIP or ISDN Use r Part (ISUP) ove r IPa portion of SS7 running on top of IPwill be the prim ary protocol. The MGC s have a conne ction to the IN (de scribe d e arlie r in this chapte r) to provide C LASS se rvice s. The MGC s re ce ive signals from the SS7 ne twork and te ll the MGs whe n to se t up IP conne ctions and with which othe r MGs the y should se t the m up. The PGW 2200, a typical MGC in this case , com m unicate s with the othe r PGW via the Ex te nde d variant of ISUP calle d EISUP. It also se parate s the D channe l from the B channe ls and forwards the D channe l inform ation to the MGC through IP. This m e chanism is calle d signaling back haul and is done via a se t of protocol adaptations de ve lope d by sigtran. SIGTR AN (Signaling Transport) is a work ing group within the IETF standards organization. The se protocols addre ss the functional and pe rform ance re quire m e nts for the transport of PSTN signaling ove r IP ne twork s. SIGTR AN he lps in ide ntifying what and how signaling protocols can be transporte d, translate d, and/or te rm inate d be twe e n IP node s and othe r node s, such as Signaling Gate ways (SG), Me dia Gate way C ontrolle rs (MGC ), Signaling End Points (SEP) and IPbase d database s or Se rvice C ontrol Points (IP-SC P).

SIP
SIP is be st de scribe d by R FC 3261, which state s that it is an application-laye r control (signaling) protocol for cre ating, m odifying, and te rm inating se ssions with one or m ore participants. Howe ve r, the re are num e rous additional R FC s de ve lope d by the IETF com m unity that com ple m e nt the core R FC to offe r ne w fe ature s with SIP as a protocol for se ssion control in VoIP, as we ll as Pack e tC able Multim e dia (PC MM), W ire le ss and Ente rprise te le phony-base d ne twork s. SIP invitations use d to cre ate se ssions carry se ssion de scriptions that allow participants to agre e on a se t of com patible m e dia type s. SIP m ak e s use of e le m e nts calle d prox y se rve rs to he lp route re que sts to the use r's curre nt location, authe nticate and authorize use rs for se rvice s, im ple m e nt provide r call-routing policie s, and provide fe ature s to use rs. SIP also provide s a re gistration function that allows use rs to upload the ir curre nt locations for use by prox y se rve rs. SIP runs on top of se ve ral diffe re nt transport protocols. A lot of im ple m e ntations of SIP are curre ntly running, although m any ve ndors and custom e rs are inte re ste d in using SIP in conjunction with H.323 or MGC P in a hybrid m ode l to allow pe e ring to othe r node s in the ne twork to de ploy e nhance d se rvice s. Se e C hapte r 12 for m ore de taile d inform ation on SIP.

H.248/MEGACO
The Me dia Gate way C ontrol Protocol (MEGAC O ) is a re sult of joint e fforts of the IETF and the ITU-T Study Group 16. The protocol de finition of this protocol is com m on te x t with ITU-T R e com m e ndation H.248.
fengnet.com/book/voip/ch01lev1sec5.html 5/6

5/10/12

Packet Telephony Network Drivers

MGC P/MEGAC O e x plode d H.323's gate k e e pe r m ode l and re m ove d the signaling control from the gate way, putting it in a m e dia gate way controlle r (MGC ) or softswitch. This de vice would control m ultiple "m e dia gate ways." Effe ctive ly, this was a de com position of the H.323 archite cture into SS7 e quivale nts, cre ating signaling inte llige nce that could act as a pe e r to the SS7 e ntitie s. In the MGC P/MEGAC O archite cture , the inte llige nce is unbundle d from the m e dia. It is a m aste r-slave protocol whe re the m aste r has absolute control and the slave sim ply e x e cute s com m ands. The m aste r is the m e dia gate way controlle r, or softswitch (or call age nt) and the slave is the m e dia gate way (this can be a VoIP gate way, a Digital Subscribe r Line Acce ss Multiple x e r (DSLAM), Multiprotocol Labe l Switching (MPLS) route r, IP phone , and so on). This is in contrast to the pe e r-to-pe e r nature of SIP and othe r m ode ls lik e that of Sk ype , whe re a clie nt can dire ctly e stablish a se ssion with anothe r clie nt. MEGAC O instructs the m e dia gate way to conne ct stre am s com ing from outside a pack e t ne twork on to a pack e t stre am such as R TP. The softswitch issue s com m ands to se nd and re ce ive m e dia from addre sse s, to ge ne rate tone s, and to m odify configuration. The archite cture , howe ve r, re quire s SIP as the protocol for com m unication be twe e n m e dia gate way controlle rs (MGC ). The k e y com pone nts of MEGAC O are as follows: Signaling Gate way (SG) Me dia Gate way C ontrol (MGC ) Me dia Gate way (MG)

Open Service Application Layer

By far the m ost inte re sting laye r of any ne twork ing protocol is the application laye r. W ithout good applications, the ne twork infrastructure is built for naught. W he n m oving to a ne w infrastructure , it is not ne ce ssary to carry ove r all the fe ature s that are on the old infrastructure . O nly the fe ature s or applications that custom e rs ne e d are re quire d. W he n building a ne twork that has ope n inte rface s from the pack e t laye r to the call-control laye r and from the call-control laye r to the application laye r, ve ndors no longe r have to de ve lop applications. Now, the y can sim ply write to the se standard APIs and have acce ss to a whole ne w infrastructure . W he n a ne w pack e t infrastructure is built, opportunitie s for ne w applications be com e wide ly available . Le gacy applications such as call-ce nte rs for e nte rprise ne twork s, and standard PSTN applications such as call waiting and call forwarding, m ust be porte d onto a ne w infrastructure without the e nd use r re alizing that the change occurre d. Afte r the se le gacy applications are porte d, lite rally thousands of ne w e nhance d applications can be spe cifically de ve lope d for pack e t infrastructure s. The se include (but are not lim ite d to) Inte rne t call waiting, push to talk , find m e -follow m e , and unifie d m e ssaging. The se applications are discusse d in C hapte r 6, "Voice ove r IP Be ne fits and Applications."

fengnet.com/book/voip/ch01lev1sec5.html

6/6