ESN LLC v. Cisco Systems, Inc. et al

Filing 83

CLAIM CONSTRUCTION SUR-REPLY BRIEF filed by Cisco Systems, Inc., Cisco-Linksys LLC. (Attachments: # 1 Exhibit R, # 2 Exhibit S, # 3 Exhibit T, # 4 Exhibit U)(Smith, Kevin)

Exhibit T

6l. ^ !

IONS : "YES , V

SL 1 A INTERNET M" PAGE 88

The Se ss ion Initiat i on P r oto c ol ( SIP ):

A K e y Componen t for

Intern t Telephony
last month, we got our first look inside the Sip standard for signaling communications services on the Internet and emerging SIP products , This month, we've gone to principal sources for a more thorough primer,

was used fordistribution ofmultimedia content , including talks and seminars , 'bioad·. of space shuttle launches , and IM qs. one of its essential componei a mechanism for inviting users to listen
in on an ongoing or future multimedia ses sion on the Internet, Basically a session initiation protocoL Thus SIP was born.

IQ ince its approval In early iggg as an official standard, the Session Initiation Protocol (SIP) has gained tremendous market ac· ceptance for signaling communications
services on the Internet, What lies behind this success? What problems loom? How does SIP fit in with other solution components? We examine these and other issues in detail.

by Jonatit A. Rosen:
fdro=Vdynamiagft.com

HISTORY
SIP has its origins in late 1996 as a compo. nent ofthe " Mbone" set of utilities and protocols. The Mbone, or multicast backbone, was an experimental. multicast network overlayed on top of the public . Internet. It

and Richard

Shockey

r sh o ckcyV ix. n ekam. com

As an Mbone tool (and as a product of the IET"P), SIP was designed with certain umptions in mind.. First was scalahili· *.'Since users could reside anywhere on the Internet, the protocol needed to work wide-area from day one., Users could be invited to lots of sessions , so the protocol needed to scale in both directions. A seo. and assumption was component reuse: Rather than inventing new protocol tools, those already developed within the im would be used, That Included things like MIME, URLs;-and SDP (already used'for other protocols , such as SAP), This resulted In a protocol that ,integrated well with other IP applications (such as web and e-mail): Interoperability was another key goal although , not one spedi=lc to ..5 . Interoperability is at the heart of IETV's process and operation , as a forum attez'd-

124

/June 2000/

m

Internet Telecom: SIP
ed by implementers and operational experts who actually build and deploy the technologies they design. To these practi· cal-minded standardixers, the KISS (Keep It Simple Stupid) principle was the best way to help ensure correctness and inter. operability.
Despite its historical strengths, SIP saw relatively slow progress throughout x996 and 1997. That's about when Interest in Internet telephony began to take off. People began to see SIP as a technology that would also work for VoiP, not just Mbone sessions . The result was an intensified effort towards completing the specification in late 1998, and completion by the end of the year. It received official approval as an RFC (Request for Comments, the official term for an IEl"F standard) in February and issuance of an RFC number, 2543, in March. bility, and -- most important - flexibility appealed to service providers and vendors who had needs that a vertically integrated protocol , such as H.323, could not address. Among service providers MCI (particularly MCI's Henry Sinnrelch , regarded as the "Pope" of SIP) led the"evangelical change. Throughout x999 and into 2000, it saw adoption by most major vendors , and an. nouncements of networks by service providers . Interoperability bake-offs were held throughout x999 , attendance doubling at each successive event. Tremendous success was achieved in interoperability among vendors . Other standards bodies began to look at SIP as well , Including ITU and BTSI TIPHON, IMTC, Softswitch Consortium, and )AIN. Looking forward, aooo will be a year in which real SIP networks are deployed, SIP vendors step forward to announce real products, and applications and services begin to appear,

WHAT DOES IT DO?
As the name implies, the session initiation protocol (SIP) is about initiation of interactive communications sessions between users. SIP also handles termination and modifications of sessions as well. SIP actually doesn't define what a #session ' is; this is described by content carried in SIP messages. Most of SIP is about the initiation part, since this is reap ly the most difficult aspect, "Initiating a session" requires determining where the user to be contacted is actually residing at

From there, industry acceptance of SIP grew exponentially. Its scalability, extensi.

(A i6,iui(1(j u i " fi-,itiC p^ i(v, euaJ UeS1yil (_S vi 0 I dlly other 3ppkation (,Nwironr )ejits area ioukincj at they tnodularity, scafability, and trans-, T pa;ellcy of SIP for their ovin rases, strong case to point, cull renablinQ r:-cornrnerce Ives) pacJes with onto-click call options.

The use

of S P by

Ottlt'r

;;Sroti,.

afl-center, SIP is perfect for ttlis envir^;rr^,. t Since the SIP user agent is very lighrtd1
l"a Jri

r)I ,rl^_ f

! ,- ^1,it is very easy to inti , c j
C? n Ie' nph rH ry

51P

rfS to ^f('dt8

phony ^ l'Is ou tl ,^t,; I^I n:^^r^ nor

s i [he' to; u5 of tn^r Pa·i? tN,> ^f, .71d lnt^^rnei
n (t4 tE CC> Ihdt ' ^^Uld a'c' ci^nllc,(

^'.lother SI

1(ior,: Ir', t'(`er (:[ill 4V.. 1 i!Iri 1. A ('0

,1nena Call c ( rl Ic; J, Tl y'^Mr

thl, ilril' CVlldlilon , the Stirl','_l) (Daly" ^nlne,

fla ys the ca fi

,.,(,

^O `^!I CAI Id slgtlois you, ';hlll' yriu a; i2 aC

fh,li

0011 corning in

^ ,';J7te(j at your dWSH.^r I:-(Jlthef ^;)

! tit c;r·^ Cnll, +,' [i!jCC

the all, or (3) sprld the uill to voicerilrail, l his appliaMtion tits into the broadci conru,.r ^i>-ps,r J cross sienaJinq environments. its standaidization, based on SIP, is takf l.) l- ^_e lri the SPIRtT5 ( Service in tl)e PSTN/tN Invoking Internet Service) v/orking q )l,p ;n Ih"1 t 0l'i,_ .f tin; r ",),I tI,nll( ', J ru"J uboLt jsulq .>.t ion, T orl rus t
prt"`sonce, affil `I(.' , It t.ipr',s

il .!7 i,> as a protocol pl ,,tf^,ln lc,, h,1, 5 ^ngc "` Ab,ollit^nlly, The meChanc:rn by
J;1"J r@7Iv' ICS Lhe lj ,,GI 'l -ever I, (,, I; ti^CndrnE'rtafly

;r ^^.rrrrn_nu^atiurls state c'.
II I ,TH,I!iUI' al :Lill 8n0 dCll

l,ersvlU to e,lal I^ ,^>>sic;n ir^f(1 ui It tc) , ! nto .+E- " Is (l n tu( i
t: 1' U;E^d tUt ; OiCP

f11 exten sion 01 SIP, q caiso fnf:,&J5, tfl ;:t ']

iri stant

fness,191WJ -

, vIll Y

tIa1lJvdifilo Yv i, o

icular moment. A user might have a PC at work, a PC at home, and an IP desk phone in the lab. A call for that user might need to ring all phones at once. Furthermore, the user might be mobile, one day at work, and the next day visiting a university. This dynamic locationinformation needs to be "taken into account in order to find the user. Once the user to be called has been located , S I P can perform its second main function ---'delivering a descriptions of the session that the user is being invited to. As mentioned, SIP itself does not know about the details of the session . What SIP does do is convey information about the protocol used to describe the session. SIP does this through tike use of multipurpose Internet mail extension$ (MIME), widely used in web and e-mail services to describe content (HT"ML , audio , video, etc,). The most common protocol used to describe sessions is the session descrip tion protocol ( SUP), described in RFC23a7. SIP can also be used to negotiate a commons format for describing sesor sions; so that other things besides SDP can be used. Once the user has been located and the session description delivered, SIP is used to convey the response to the session initiation (accept, reject , etc.). If accepted, the sessions is now active. SIP ' modify the session as well. Doing so is easy ' - the'originator simply re-initiates the session , sending the same message as the original, but with a new session description. For this reason, modification of sessions (which includes
Corrsputa T'ekphwsy,wm/1= e,zooo/12 5

nternet Telecom: SIP
where Jo is currently sitting. How does it know which PC Joe is at? SIP defines another request, called REGISTER, which is used to inform a proxy of an address binding. In this case, when Joe turned on his SIP client on his PC, the client would register the binding sip:joef)sales.engineering.com to sip:joe(Mmypc. sales .foo.com. This would allow the proxy to know that Joe is actually at mypc, a specific host on the network. The bindings registered through SIP are periodically refreshed, so that if the PC crashes, the binding is eventually removed. The sales.foo.com proxy consults this registration database, and forwards the INVITE to joeQ)mypc.sales .foo.com (Step 8). This INVITE then reaches Joe at his PC. Joe can then respond to it (thus the request-response model). SIP provides many responses, and these include acceptance, rejection, redirection, busy, and so on. The response is forwarded back through the proxies to the original caller (Steps 9,10,11,12). An acknowledgement is sent (another type of request, called ACK) in Step r3, and the session is established. Media can then flow (Step 14). SIP is patterned after HTTP in many ways. HTTP is also request-response. SIP borrows much of the syntax and semantics from HTTP. The textual message formatting, usage ofheaders, MIME support, and many headers are identical. An http expert looking at a SIP message would have difficulty distinguishing them.

Figure 1 : Session initiation in SIP, things like adding and removing audio streams, adding video, changing codecs, hold and mute) are easily supported with SIP, so long as the session description protocol can support them (SDP supports all of the above). Finally, SIP can be used to terminate the session (i.e., hang up). tiple locations , in the hopes of finding the desired user at one of them. A close anal. ogy is the home phone line service, where all phones in the home ring at once. Consider the scenario'in Figure r. In our example, the caller ([e-mail]) wishes to place a call to [e-mail]. Jdrosen sends his SIP INVITE message to the proxy for dynamicsoft.com (Step 1). This proxy then forwards the request out to Columbia, where it reaches the Columbia.edu server (Step 2). This server is actually not a proxy, but a similar device called a redirect server. Instead of forwarding calls, a redirect server asks the requester to contact the next server directly. The Colurnbia.edu server looks up Joe in its database, and determines that today, Joe is on sabbatical to foo.com. It therefore sends a special response, called a redirect, to the dynamicsoft.com proxy, instructing it to instead try [e-mail] (Step 3). The dynamicsoft proxy then acts on this response , which means it directly tries to contact [e-mail]. So, its sends the INVITE to the foo.com server (step 4). This server consults its database (Step, g), and learns (Step 6) that Joe is actually in sales. So, it constructs a new URL, joe@ sales. foo.com, and sends the INVITE to the sales .foo.com proxy (Step 7). The proxy for the sales department then needs to forward the INVITE to the PC

HOW DOES IT WORK?
SIP is based on the request-response paradigm. To initiate a session , the caller (known as the User Agent Client, or UAC ) sends a request (called an INVITE), addressed to the person the caller wants to talk to. In SIP, addresses are URLs. SIP defines a URL format that is very similar to the popular mailto URL. If the user's email address is jdrosenC)dynamicsoft.com, their SIP URL would be sip:[e-mail]. This message is not sent directly to the called party, but rather to an entity known as a prt server . The proxy server is responsible routing and delivering messages to the called party. The called party then sends a response , accepting or rejecting the invita. tion, which is forwarded back through the same set of proxies, in reverse order. A proxy can receive a single INVITE request , and send out more than one INVITE request to different addresses. This feature, aptly called "forking," allows a session initiation attempt to reach mul-

MAIN ADVANTAGES
Services: Internet telephony began on the premise that it was cheaper than nor. mal phone calling. Users were willing to tolerate degraded quality or reduced function for lower cost. However, the cost differentials are rapidly disappearing. To continue to exist, Internet telephony must find another reason to be. The answer is services. Some of the most exciting applications have already found killer status on the Internet, though not (yet) in the form of multimedia services. Now think of integrating multimedia communications, such as

126/June zooo/ComputerTelephony.com

Internet Telecom: SIP

0;

vto- fir cwlr,a I''tol BCt1"^L,JCt to

iar ice. 01)o I^, ti ?3, wlrkh has hz.iSicully
uo, r, iwshrrJ by big irl,ryers in Qv tclrn"k

`,1[,.0 Mat

ovuryl)ody t.,:ln comilluni-

th . r " "2 of Ike s,k-v icn 111,0,l iun ;:ratoi (SIP) for IP teleptiony signaling, and, we *ith t ood t etason. The innovation that
Wf.; vc, ialreody seen urr)c?rqe horn SIP initia, t7vo , 15 ord''y,) taste tat what 1Ve believe to 1,e

r otc Kh everybody else in an illy xpendve and effective way, E e-_utives sometimes ask rile, 'Why all this talk about protocol,,, why should i be interested in protocols?' I have to explain that soon, the core of our business will be bosed on these protocols."

r indmtry who weriit to enter the'cur nmunicabons business. My persona opinion is that H.323 has oftrfctiveaiy already faded in the US, wd N now M arcing to QH ovep sea % nwinfy because it a based on an I` DN rarchiteoure. I fie second cramp is SIP, which is thQ prate Internet play. The thi> 1, wtilcfrlrcorasider to be ttW most d,ancJemus and potentirilly negrative, is thoso

the Prc>tt) oTs IndlentAl. Ne"AhVWY4 whit owes the runt sense todmittl(agii:atiy is not
fafi4`tays what wros it trio R1^1I K( t,j)Jra _C'. We

wwo tti lorc^ pleasantly .u,rpfised to dis u
t^,+,, r, ^'trrf " ', ri iri ca rriers to beat,, Coin

THE NEW SERVICE PARADIGM
Mike MCI, Stalup carrier Level 3 entyred

^

nl!ttod a^) t1

err C.oinFau,rratty to thV cie

yr f, 1,^:^nt _3: o adoption of SIP. MC: WoriclCorn, tinder, t1w direction of fienry Sinn)oich, Distinquished Melnbe r at iginoof iS now carrying out uric, of tue rilost sopnir hceated rrnpir>mr:n a ions of SIP to data MCf has ,akeady clexkWed its own SIt'rc'dkoctQroxy/locMion serwws, and is wear koig with other vendors in areas like soltswitchas and IP tvlc:phones. iri '`.fPt)i

in the teleamn industry who area trying to p roserv e circuit-sw t(ted control and signaling sysWrns, rrsirtg Me Interrret as just a cheaper win, The W agent in the case of FMGCP or MITGACQ for example, is essen orally Mere to pineserve the signI and control architecture of SS7 and the intelligent NOwork: The software, of course, is ad proprietary, so that Me ven, dor who hup;=smunts the caU. xager is and
t ,:
Ccn'

he rnarketur^ ncun, '.iered by tan e.vrrtii)y sir
-,ulit-switcho,J ailr.,structure. L(?v4Ci ^ als'u noes not provide services directly tea end users, but offers its network infrastructure to rather service providers, Almost from day tine; the carrier was cpmrnittec to SIP. Matt Johnson, product marketing manager for Level 3`s Dynamic Bandwidth Applications

candSoftswitch-Enabled Services Group, Buys
Mat by pushing more fl&UNe nce out to the rn:t.^ork t n:ip^:)int , `!P can' generally irn lA fy lho systemsrrrtiujrcd in the rirh.oi't.." _cvel 3 also t,3heS a very strater^iC Pcisition ors thr olts^llch's rule in net,vol a in-

.-hc5 in th,? car rioi 1-s nl two! K
aver that C,)rricr; iCE"

HW q tire:: vices can now be appNed to ti 'I1 SW V tecNiVal elug ance More'' wadd tsar s win c,lrr ier adoption , of courso "Thrr idea is srrot,kY s<ayh Suntan rich, "'Yoo OW>9 stoney in new netwof t; infrastructure offly it it can

fus h n surrounds the relration of protocols We the Modh Gateway ; Control Pwtocol (MGM and ME"GACJ ( its likely ;anew sor) to SIP, as they we e:ornplemeMary in cortaira ways and muWaIN exclusPve A oMers. Si mIr?l h exNairim howenk "M(iC

Con

TURF PROTECTION

irwhocture . According to idu rsn, "The s'oftswitchshould behave: basically as a web server behEavos, providing a kind .of , '.dumb intelligence."' In Love[ S's network, softswitches are ptattorrns that provide

tr'Ag new revenue;. And new invenue copws Rom servive; that donl 6it today.
On the web, we've air e ady se L ra an explo .

d hAEGAC0 rare great proWmis for internal :,^ cantr^..!Iir,gan WteloolonyOah-vv,iyISO In on 1my,ar? and nS `Vr,hIAP1um, a!

open interfaces to services, but do not thearnselves contain the service intellirtce. SIP, because it facilitates point-towriecti,, ns is crucial to this rnodwi Yet L rT^cl 3 cl , SY tlotjust as a $ qT 1,aliri5, pr utucul, but t;s an arobtingtechnclogy nor a fun^larw^nl<III"''IIHt ^IL'Ilt;v^ly<sfdrfi.erlf;o tobconi ;E rw',Cei;. Levi i Ts e'l,tk u Lt!,:rr s rnoael, in fact, Losed on the idea W a so9wed Services. "We're focused on.;! c,if tying out ari eriablinq' t<<ate,gy," John'..Seal explains, "We won't env Much the end user directly with our n^t,.ur but we will enable ASPS or ITSPs to provide innovative applications to the end user. In effect were turning the revenue= mode[ of tradition;^l i 4tworks inside nut, by g vinc},customevs access to the servictas tlw ,v.lnt frorn :any, number of different providers

Sion of new rrlt.ilbilled[a St' NI P& So
(LL<art,WJA / a set of 44 e vaWd web /^7^3L[ , 015

trio' would rn<·iudr; tvlephony t`rre new survoes is

t, w

Ow r s,'n'h&v ant:; Ian fate in Me (AthesOlsbitchorcail ja r t ;yrlrir r_

ac w A

site "now, servJ(,w,," is already
mantra in rfisr usSions of Inivinet tMocotn Soars: of the real "newness" that convergence prt2aY bes hats been A bond,
In tho wof .,t cjs1?s, the"froxt`c)e'n" net,

y lirnitinq the user's access to a proM i ry group of appkatiora swvw, tht
M IN or IMEGACO call agent basically rein vents -unequtal racces, [of the PSTNI, only none RJ located at the control I,..,(ft vper>ra it used to be at the transport lever.,' While some try to avoid aking such strong positions on VUIP protocols by claiming "protpCOiag^osticisrrr^" Sinni-eich sees ads notion as untenable. "'r he Internet id the wears am nothf, ig but <a collection of

work starts to look airnost wenticcd to the -fecj aa.ay 'f ic.twoi k, Slnnrewh Limnos this dike
an Nind we au]nee on cart jef s' (.aiid s;,quip-

n7vnt vendors' desire to protect their tradi-

tional source, of mvc tikw, E his turn` wear, he
say* is refimteflM M p iatocnllenL "At this point, you ba3sic ally have three

, protocols. whicft have been so wait do-

Compute'Praephony . oorm/June sago/12?

Internet Telecom: SIP
voice, with web, e-mail, buddy lists, instant messaging, and online games . Whole new sets of features, services, and applications become conceivable. SIP is ideally suited here. Its use of URLs, its support for MIME and carriage of arbitrary content (SIP can carry images, MP3s , even Java applets), and its usage ofemail routing mechanisms, means that it can integrate well with these other applications . For example, it is just as easy to redirect a user to another phone as it is to redirect a user to a web page. Scalability: SIP uses the Internet model for scalability - fast and simple in the core, smarter with less volume in the periphery. To accomplish this, SIP defines several types of proxy servers. "Call-stateful" proxies generally live at the edge of the network. These proxies track call state, and can provide rich sets of services based on this knowledge. Closer to the core, "transactionstateful " (also known as just "stateful") proxies track requests and responses, but have no knowledge of session or call state. Once a session invitation is accepted, the proxy forgets about it. When the session termination arrives, the proxy forwards it without needing to know about the session. Finally, "stateless" proxies exist in the core. These proxies receive requests, like INVITE, forward them, and immediately forget. The SIP protocol provides facilities to ensure that the response can be correctly routed back to the caller, Stateless proxies are very fast, but can provide few services. Call-stateful proxies are not as fast, but they live at the periphery, where call volumes are lower. Extensibility : History has taught Internet engineers that protocols get extended and used in ways they never intended (e-mail and web are both excellent examples of this). So, they've learned to design in support for extensibility from the outset. SIP has numerous mechanisms to support extensions. It does not require everyone to implement the extensions . Facilities are provided that allow two parties to determine the common set of capabilities, so that a session initiation can always be completed, no matter what. Flexibility: SIP is not a complete system for Internet telephony. It does not dictate architecture, usage patterns, or deployment scenario. It does not mandate how many servers there are, how they are connected, or where they reside. This leaves operators tremendous flexibility in how the protocol is used and deployed. One way to think of it is that SIP is a LEGO block, operators can piece together a complete solution by obtaining other LEGO blocks, and putting them together in the way that they see fit. ENUM and TRIP Although the standard method of connecting with SIP servers is to use an e-mail-like address such as sip:[e-mail], that will not be helpful if all you have is a telephone number. Though many people will use SIP directly from their PC, we still have billions of telephones in use that only have 12-key entry capability. We tend to think of phone calls as using phone numbers, so why should SIP (or any other form of Internet telephony) use a different form of identification? This is particularly important since the PSTN is not going to go away anytime soon. Fortunately, SIP can easily carry phone numbers, using the new telephone URL (tel:5551z12, for example). The question is - if all you have is a telephone number, how do you find a SIP resource (or any other resource for that matter) on the Internet that is associated with that telephone number? When the SIP address is an e-mail-like identifier, the resource is easily found through a DNS query, since the e-mail-like identifier contains a domain name. The problem is harder for phone numbers. Addressing this problem is the task that the IETF ENUM WG (Telephone Number Resolution Working Group) has set for itself. This work is in an advanced stage of development, so we can speak with some confidence on the shape of the ultimate output, and its implications for SIP and Internet telephony in general.
Telephone numbers are well understood.11,eir definition has been the work of the ITU (International Telecommunications

Union). The formatting and structure of telephone numbers is defined in recommendation E.164. These numbers can be no larger than 15 digits and are globally unique. The ENUM plan is to enter telephone numbers into the Internet DNS [domain name system) so that any application, including SIP , can discover resources available to that globally unique phone number. The technique would work something like this. Take a phone number [1.212-6918215 ] and translate it into a format that the DNS system can understand , such as 5.r.2.8.i.9.6.2.1.z.r.er64.f00. (Don't worry. As a SIP user you will never have to figure out how to reverse type in phone numbers. Your SIP phone or SIP proxy will do this for you automatically.) Each and every digit to the left of the domain is a zone in DNS terms, and authority for zones can be delegated at each digit. This permits both individuals and enterprises the ultimate right to decide what Internet services are available for this number. If, perhaps, you have plugged a SIP phone into your network, you simply dial a phone number as you always have. The SIP phone or proxy server would do the number domain translation and through classic DNS resolution discover a DNS Resource Record that essentially says 1.212-691-8215 can be reached by SIP by contacting [e-mail]. Your SIP UA would then follow standard SIP procedures, and call the user manning the main number at the Computer Telephony offices. Interestingly, the ENUM mechanism gives even wider flexibility than this. Instead ofcontaining just SIP URLs, the DNS entries can contain e-mail addresses for VPIM- based universal messaging or LDAP-based white page resources for advanced caller identification. The DNS entries could even contain H.323 addressing information. In fact, any URL can be placed inside, allowing clients to be contacted using a variety of communications mechanisms. ENUM depends , of course, on a particular phone number having some kind of resource on the Internet associated with it. However, the vast majority of phone num-

28 /111e aooo/ComputerTelephony.com

I

nternet Telecom: SIR
A server can easily parse and validate a CPL, guarding against malicious behavior. , The running time and resource requirements of a CPL can also be computed automatically from the CPL. An interpreter for CPL is very lightweight, allowing CPL services to execute very quickly . For these reasons, it is possible for an end user to write a CPL (typically with some kind of GUI tool), upload it to the network, and have it instantly verified and instantiated in real time. At the opposite end of the spectrum in SIP is CGI (the common gateway interface). Many web designers are familiar with HTTP CGI; it's an interface that allows people to generate dynamic web content using Perl, Td, or any other programming language of choice. Since HTrP and SIP are so similar, it was recognized that an almost identical interface could be used for SIP. The result is SIP CGI, which is roughly go% equivalent to HT17P CGI. Like HTrP CGI, SIP CGI passes message parameters through environment variables to a script that runs in a separate process . The process sends instructions back to the server through its standard output file descriptor. The benefit of SIP CGI is that it makes development of SIP services work much like the creation of dynamic web content. In fact, for SIP services that contain substantial web components, development will closely mirror web-only services. The importance of leveraging web tools for voice service creation is that a much larger class of developers becomes available. CGI has substantially more flexibility than CPL (CGI doesn't even mandate a particular programming language), but is much more risky to execute. Furthermore, because of its usage of separate processes, SIP CGI doesn't scale as well as CPL. Somewhere in the middle are SIP Servlets. HTI'P Servlets are in wide use for developing dynamic web content. Servlets are very similar to the CGI concept. However, instead of using a separate process, messages are passed to a class that runs within a JVM (Java Virtual Machine) inside of the server. As a result, Servlets are re-

bers correspond to simple PSTN phones. These numbers will have no corresponding entries in the DNS. To contact them, a SIP phone must route a call to a telephone gateway, which connects to the PSTN. Normally, a service provider does not own all the gateways that can be used to terminate a call from one of its users . It enters into peering relationships, through clearinghouses or settlement organizations , to have access to a wider set of gateway services. That being the case, how does a service provider know which of its peers has gateways that can terminate a call to a particular number? This problem calls for some kind of routing protocol that allows service providers to exchange routes. That is the idea behind the TRIP (telephony routing over IP) Protocol, being developed by the IPTEL working group in the IETF. Based on the well-known border gateway protocol(BGP), TRIP servers (often collocated with SIP proxies ) maintain and exchange information on what gateways are available to establish calls to ranges of telephone numbers. Like BGP, TRIP provides support for aggregation, scalability, and reliability. Gateway failures are quickly detected, and alternates are used instead. TRIP permits multiple service providers to route calls through each others' gateways, thus optimizing the capital cost of each provider in a particular service region, and avoiding unnecessary duplication or over-provisioning of gateways. SIP SERVICE PROVISIONING Beyond $I P's ability to create new, innovative services , the protocol has the potential for making service creation available to the "masses ," in much the same way as web content. These services can be created by service providers, enterprise administrators , and IT departments, or even directly by the end users. By opening up innovation to the public at large, all sorts of new services and features can be developed , creating entire new markets. We have seen the same thing in the web space - - the accessibility of the web has fostered a huge market for e-commerce, since anyone with an idea and a few dol-

tars can put together new content. In overcoming the highly centralized and carrier-controlled model of telephony, and in putting tools for service creation in so many hands , SIP has here the potential to deliver what the PSTN Intelligent Network only promised. What kind of services or applications could be enabled by SIP? Besides the traditional call-forwarding, follow-me, and do-not-disturb, SIP has the potential for enabling a whole new class of services that integrate multimedia with web, email, instant messaging , and "presence" (meant here as, "are you currently online?"). The value that the Internet brings to Internet telephony is the suite of existing applications that can be merged with voice and video communications. As an example, at the end of a call, a user can transfer the other party to a web page instead of another phone. This transfer would end the call, and cause the. other party's web browser to jump to the new page. In essence , the value of VolP and SIP comes not from integration at the network layer (i.e., run your voice services on top of your data network), but at the services layer (i.e., combine your voice services with your data services). HOW TO PROGRAM IT? Developing services , of course, requires APIs. What kind of APIs are used to program services delivered by SIP? There has been significant activity in this area, resulting in numerous new interfaces, each with its own distinct set of strengths and weaknesses. The first API that surfaced is the call processing language (CPL). CPL is not actually an API, but rather an XML-based scripting language for describing call services . It is not a complete programming language, either. It has primitives for making decisions based on call properties, such as time-of-day, caller, called party, and priority, and then taking actions , such as forwarding calls , rejecting calls, redirecting calls, and sending email. CPL is engineered for end-user service creation,

ComputerTelephony .cow/June 2ooo/129

stricted to Java , but suffer less overhead than SIP CGI, Use of a JVM for executing servlets means that the Java " sandbox" concept can be applied to protect the server from the script. Lake SIP CGI, SIP Servlets closely mirror the operation of HTTP Servlets ; they simply enhance the interface to support the wider array of functions a proxy can execute, as compared to an HTTP origin server. Besides these new APIs , traditional APIs ( such as JAIN , Parlay , JTAPL, and TAPI ) can also be used to develop SIP services . However , the telephony focuq of these APIs restricts them from performing services that take advantage of S I Ps unique capabilities , such as integration with web and e-mail.

QUALITY OF SERVICE
Perhaps the most vexing problem in voiceover - IP, in general, has been the issue of quality of service. The delay in conversations that many VoIP users encounter is caused by the jitter and latency of packet delivery within the Internet itself. It's useful to review some of the basic principles of the Internet to understand what can be done about the problem, what the IETF's response has been, and how it impacts SIP. Currently , the Internet offers a single service, traditionally referred to as "best effort." In other words, all packets are created equal . There is no difference to the Internet whether a packet is e-mail , FTP, or the download of a web page. If the Internet gets very busy , packets get dropped or delayed Unfortunately , the human ear is extremely sensitive to latency in the delivery of sound. The human ear can detect delays of2oo milliseconds or greater in voice conversations. ' SIP itselfdoes not get involved in reservation of network resources or admission control. This is because SIP messages may not even run over the same networks that the voice packets traverse. The complete independence of the SIP path and the voice path enables ASPs to provide voice services without providing network connectivity. This is an extremely important advantage of the SIP architecture. Given this , SIP re-

lies on other protocols and techniques in order to provide quality of service. Most users have dealt with QoS issues by either adding bandwidth to their networks, or by applying complex and expensive framing techniques , such as ATM, to I P traffic. This may be sensible for intra-enterprise Vol P configurations , since the network can be administered directly. However , when Internet traffic must exit a domain or a particular carrier boundary, all bets are off; other methods must be used. To create QoS on the Internet, you must create different classes of service for packets. The IETF has taken two approaches: The first is Integrated Services ( RFC22rr and RFC2212 ), also known as INTSERV. The second is Differentiated Services (RFC2475 ), or DIFFSERV. Describing these two techniques is another article in itself, but they can be summarized. INTSERV essentially creates an endto-end private lane for packet voice traffic that is opened and monitored by each router along the path and the endpoints. No packets are sent out unless the entire route signals its ability to meet and guarantee the service requirements for the call. The protocol used to reserve the resources in the network, and get confirmation of those resources , is known as RSVP, or the resource reservation protocol (RFC2205). DIFFSERV creates classes of service, and controls the admission of that traffic onto the Internet, by filtering packets at the edge of the network . Here, there are no explicit requests for resources from the net. work . The advantage to the DIFFSERV approach is that it does not require the maintenance of network state by all elements, and thus scales better than RSVP. Clearly, the INTSERV approach offers the highest level of quality for sensitive applications , such as voice. For SIP, this means the transparent integration of two forms of signali n g: first, the signaling to set up the call (nsing SIP) and - once the media addresses and codecs are agreed upon - the second, for setting up QoS using RSVP. This separation of session establish-

ment and QoS reservation . introduces an interesting side effect: One may succeed (namely, the call setup), while the other (resource reservation) can fail , The result is that the phone may ring and be answered, even though the network cannot support the call. To handle this problem, a coupling mechanism has been developed for SIP based on work done initially within the PacketCable Forum Distributed Call Signaling ( DCS) group. This coupling allows the SIP INVITE (specifically, the SDP), to contain indicators that tell the called user not to "ring the phone" until sufficient re sources have been reserved (using RSVP or some other mechanism). Once the reservations have succeeded, the caller sends a new request, tentatively dubbed "PRECONDITIONS-MET," to the called user, indicating that resources are available, and the phone should ring . Of course, if the QoS reservation fails, the call can optionally proceed with best effort. This means that SIP systems can make use of comprehensive end-to-end QoS models for Internet telephony. Since SIP itself does not specify those mechanisms, new and more comprehensive QoS services that are discovered can be used without affecting SIP.

RELATED PROTOCOLS COMPARED: Admittedly, SIP is hardly the only protocol in the VoIP space. Two others are closely related to SIP - H.323 and MGCP. (We group IPDC, SGCP, Megaco, and H.248 together with MGCP for purposes of this discussion).
H.3Z3 The ITU developed H.323 . Version x was standardized in 1996 . Its focus was multimedia communications services for IANs without QoS . H-323 v.x was not targeted for IP specifically , but rather for any type, of packet IAN. It had numerous shortcomings for Internet telephony, some of which were addressed in Version 2, released in 1998. Version 3 has been recently completed, and Version 4 is now under development.

132 /June zooo/compute'Pelephony.com

tternet Telecom: SIFT
H.323 is a complete , vertically integrated suite of protocols and an architecture for delivering multimedia conferencing applications. It includes signaling, registration, admission control , security, interworking requirements with H.320, H.321 , and other ITU conferencing systems , inter-domain data exchange , transport, and codecs . H.3,z3 defines several entities , including terminals ( end systems , like PCs ), gateways , multipoint conferencing units , and something called a gatekeeper. A gatekeeper is similar to a SIP proxy, in that it plays the role of a signaling relay. There are numerous differences' between SIP and H . 323. The first is scope ; H.323 specifies a complete , vertically integrated system. Not touch room is left for flexibility or different- architectures , SIP, on the other hand, is a single component. It works with RTP, for example, but does not mandate it. SIP systems can be composed into a variety of architectures , and numerous protocols and additional systems can be plugged in at the discretion of the service provider. SIP can be considered a building block, whereas H.323 is a specific system. The flip side of this determinism is that H.323 does numerous things that SIP, purposefully, does not address. For example , one of the H , 323 protocols, H.a.45 , contains powerful mechanisms for conference control for distributed multiparty conferences. This conference control allows a chairman ' to grant or deny speaking privileges to other conference participants . This kind of control is possible within a SIP-established conference , but it is not addressed by SIP itself, and there are currently no standalone standard protocols that can do this. H.3z3 has its origins as a LAN protocol; numerous enhancements (such as FastStart) were added to address usage as a wide-area protocol. SIP, in contrast, was designed from day one as a wide-area pro. tocol. SIP's support for fast, stateless proxies in the core, and call stateful prox ies in the periphery, adds significant seal. ability here. Furthermore , its ability to pass data to clients , and have it reflected back, means that state can be pushed to the periphery (several headers, such as Via and Record-Route, provide that capa. bility). These are absent in H.3x3.

Many of the other differences stein, in general , from the different histories and design philosophies of the protocols' par:: ent organizations. ITU's H.323 borrows its call-signaling component from existing work done In ITU , namely the Q.g;r protocol, used for user-to-network signal. ing in ISDN.
SIP, on the other hand, borrows much of its concepts from H TP, also developed within ILf'I'F. The result is that H.323 has much more of a telephony. centric flavor , while SIP has more of a web flavor. Intimately tied to this are SIP's facilities, which allow it to integrate with web, e-mail, and other existing IP applications. Wherever SIP has a field where a SIP URL can appear, any other URL type can be present. SIP's powerful and extensive URL definition allows for SIP URLs to be embedded in web browsers and e-mail tools. H.323 has no URL format. Since applications that integrate web, e-mail, buddy lists , IM, and other IP applications with voice are likely to be the killer app for VoIP , this fund tionality is critical. SIP's allegiance to the KISS ;( Keep It Simple Stupid) principle has made It generally easier to implement and interoper. ate. To illustrate: H,245 has another set of functions that allow for very powerful multimedia capability negotiation between participants. This negotiation allows each side to convey sets of capabilities , and to de· scribe interactions between there. ("I can do G.723 . 1 compression with H . 263 but only without H-frames , but I can do G.729 with H.a6r ")

EM" 46 on cars, or 0 www.cor WerteieOw V conVprWvct1nfo

1.34/j,

nternet Telecom: SIP
SIP can be extended in numerous ways, including adding headers , new methods, new bodies, and parameters to existing headers. Therefore , it is less restrictive than H.323 in where new things can be placed. The history of the Internet shown that protocols
Rpre 2: MGCP and SIP Used Together, get used in ways never in. tended; that extensions get developed, used , and sometimes fade away. Support for this kind of evolution is critical for long-term success. MGCP MGCP (and its relatives) was conceived as a tool for decomposing a telephony gateway into a controlling signaling component and a controlled. media component. The protocol allows

trated in Figure a. MGCP can also control' an IP phone (See Figure 3).: The controller acts as a PBX or Class g switch, providing every possible service to the phone: receiving off-book signal, instructing the phone (which is the controlled media gateway) to send dialtone, receiving dialed digits, and launching a SIP INVITE to,connect the call. When the response comes, the controller tells the phone to send'mtdia to the appropriate location, and to receive media and play;itoutthe.speakera.
In this:application, MGCP "competes" with SIP in the sense that instead ofMGCP, SIP could have been placed in the phone,

figure 3: MGCP for phone control.

SIP (actually, SDP) negotiates much simpler capabilities ---- just a list of coders, in order of preferences, for a particular media stream. Experience has shown that in practice , this is sufficient, Another i mportant difference is exten. sibility , Both protocols can be extended; but differ signif candy in method. H-323 defines protocol elements called non. StandardParams , which are sprinkled throughout he protocol. Vendors can add non-standard elements, identified by a vendor ID . H.323 can also be extended through a version change. Versions must be completely backward compatible, ensuring that each version of the protocol takes up more room than its predecessor.
SI P, on the other hand , allows for standards-based extensions to perform specific functions. implementations can implement different sets of extensions depending on their needs. SIP takes care of intemperability=in this environment by providing a ;powerful set of tools for indicating and negotiating the set of exten. sions used in requests and responses,

the controller to instruct the controlled to send and receive media ifc addresses, generate tones, and modify configuration. The protocol also sees that the controlled entity reports back to the controller, when detecting DTMP digits and tones , for example. MGCP performs a much different function than SIP does . In fact, a complete system cannot be built with MGCP alone. A session initiation protocol is still needed between separate controllers . This is illus.

There is a substantial difference in these two approaches. The MGCP ap. proach assumes the phone is nothing more than a dumb black phone with the standard twelve buttons, The system cannot support any services beyond thosertraditional PSTN services This is not sur. prising, since the architecture closely mirrors the way residential phone service is provided today. Services are pushed back into the network, even -ifthey don't necessarily needto be there.
Some argue that pushing-services back into the network enhances servavailabil· ity. However, an MGCP phone cannot sup. port any of the advanced and new features that the Internet can bring. Furthermme, a user eaimot even make a phone call without a controller providing the service. In both SIP and H.323, users can call each other without proxiiesorgattekreepens. Someargue

1:!r' t

6u., ,e: www.cs,columbia . edu/-hgs/sip/

nu i^ S! F' ,dG fdUrrte^,a,:;^_ tivwwsottannor.com/sipvrgl LW': [,,i ww.ietf.org/html.charters/enum-charter.htrnl ENU,,: Dicift iii; search i etforg / intern,et-drdits/draft-faltstroni-el64 -05.txt F:NUM Graft #2: search , letf.org /internet - drafts / draft-vaudreuil -enum-L-164dir,00.txt
DNS ;_one Redirection: www.rfc-editororg/rfc/rfc2672.txt IPTEL. Charter www.iett-org/html.charters/iptel-chaitQr.Pitml TRIP Ufa n! ^,^^It; www.gall labscorri/mailing Itstsliptel/ PINT: www.ietf.org/htrrlCcharters/pint-cliarter.html

Sf^IRIT5`. ,vww.ietf.org/htmf.chart^^rs/spirits-charter.htrnl

/June aooo /

13.5

Internet Telecom: SIP
that this is strength of this architecture, not a weakness . However , the Internet is what it is - and that is a medium that allows any two users to contact each other , independent of the application . Forcing communications through some entity without providing value just means that end systems will be upgraded with software that has no such restriction ( like a SIP client). INTEROPERABILITY Since SIP was approved as an RFC in March 1999 , four interoperability bakeoffs have been held. Only ten or so implementations were tested at the first bakeoff; 45 were tested at the most recent one , in April. These implementations represent a wide cross section of the industry , including large gateway vendors such as Cisco; standalone phones such as Pingtel; proxy vendors such as dynamicsoft ; PC clients such as Netspeak; service providers such as MCI; and protocol analyzers such as Agilent (formerly Hewlett Packard). Success at these events has been astronomical . At the third bakeoff, a complex testing scenario included seven elements (three proxies and four user agents) from seven different vendors . The call was originated from a user agent , and sent to one of the proxies. The proxy provided a cryptographic challenge to the originator, who then retried the call setup automatically with security credentials . The credentials were verified , and the INVITE was forked to two proxies . One of those forked once more , causing three phones to ring simultaneously. One of them answered , causing the others to stop ringing. The scenario also involved a TCP-toUDP conversion , and a complex application of SIP's Record Routing capability, This scenario was successfully executed several times during the event. network address translators ( NATs). There are similar issues when running SIP and H . 323 through firewalls, NATs break many protocols that act as establishment mechanisms for other protocols , such as SIP . NATs provide a boundary between the private IP addressing of a network and the public Internet. They are most often used if an enterprise is unable to secure access to a sufficient block of IP numbers from their ISP, or if the enterprise wants the presumed luxury of being able to switch ISPs without having to renumber their network. SIP, fundamentally, is a control channel for establishing other sessions (namely, the media sessions ). These kinds of protocols (of which FTP and H.323 .are other exam. ples) cause problems for NATs, since the addresses for the established sessions are in the body of the application layer messages , as we see in the session description protocol examples shown in the sidebar, "SIP Call Flow Examples." When used with SDP , SIP messages carry the IP addresses and ports to be used for the media sessions . There may be mul. tiple media sessions withina particular SIP call. Since SDP carries IP addresses and not host names , the external caller user agent will send media to an I P address that is not globally routable. It is only a valid I P address within the private network. A nearly identical problem exists for firewalls . When a user inside the firewall sends media to an address outside the f rewall, it will be dropped by the firewall unless a rule is established to allow it to pass. Since the media is sent on dynamic ports to dynamic addresses , these rules must be dynamically installed through application - aware devices , such as proxies. There is no easy solution to the problem of NATs . Anyone considering VoIP deployments should be aware of the hmitations they present. A "Birds of a Feather" ( BoF) session was held at the 47th IETF in Adelaide , Australia , called FOGLAMPS, to investigate solutions to this problem. will move through the IETF process, from proposed standard RFC to the next stage, draft standard RFC. As proposed standard RFC, standards begin to get deployed and gain implementation experience . Invariably, problems and inconsistencies are found , and these are corrected as the draft RFC version is built. Interoperability of every feature must be demonstrated and documented , and two interoperable implementations must exist. Numerous extensions are also under development . Several of these fall under the umbrella of "SIP-T," or "SIP for telephony," providing a way for traditional PSTN signaling messages , such as ISUP, to be carried in SIP messages . This allows SIP to be used between gateways or softswitches in a way that provides complete transparency while retaining its strengths and services. Another extension is aimed at connecting the caller to the right terminal for a given user. Called " caller preferences" and "callee capabilities ," the extension incorporates presence information (i.e., buddy lists ) into SIP messages . A caller can request a call for joe (Mcompany . com to be routed to Joe ' s mobile phone , or to a PC client that supports video. Much work is also in progress on supporting infrastructure. This includes an SNMP Management Information Base (MIB) for management of SIP servers, gateways , and clients, DHCP option codes for SIP to support autoconfiguration, and QoS mechanisms that permit SIP sessions to take place only if sufficient bandwidth exists to support them. * Jonathan D. Rosenberg is the Chief Scientist of dynamicsoft (wwwAynamicsoft . com), He is the co-author of SIP (RFC2543), the chair of the IETF IPTEL work group , and the cochair of the IETF SIP work group. Richard Shockey is the principal of Shockey Consulting LLC. He is the co-chair of the IETF ENUM work group and chair of the IETF BOF work on QUALDOCS. He is also senior technical industry liaison at NeuStar, Inc.(www.neustancom).

OK, WHAT ' S THE BAD NEWS.... If SIP sounds too good to be true ... well, you know the saying, Emerging issues in the Internet could ruin the promise of SIP (as well as H.323) over the long term. The problem is the increasing shortage of IP v4 numbers and the growing use of

FUTURE DIRECTIONS
Where does SIP go from here? SIP.itself

136 /june2ooo /CornputerTelephony.com