20
| WHITE PAPER | Practical Far-End NAT Traversal for VoIP March 2006

Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Embed Size (px)

Citation preview

Page 1: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

| W H I T E P A P E R |

Practical Far-End NAT Traversal for VoIP

March 2006

Page 2: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Contents

Copyright © 2007 Ditech Networks 2/20

Introduction...............................................................................................................................3

PacketAdmissionPolicyProblems................................................................................................3

PacketAdmissionPolicyModes...........................................................................................3

PinholeTimeoutThresholds....................................................................................................4

SignalingAsymmetry..............................................................................................................4

Client-SideSignalingAsymmetry.........................................................................................4

Server-SideSignalingAsymmetry.........................................................................................5

OutboundCallsand2-WayMedia...........................................................................................5

REGISTERPacketandInboundCalls.........................................................................................6

NetworkandPortTranslationProblems........................................................................................7

NATPortContentionandPortRotation ...................................................................................8

NATandMedia......................................................................................................................9

CommonAttemptstoSolvetheProblems....................................................................................11

UsingTCP.............................................................................................................................11

UPnP....................................................................................................................................11

STUN....................................................................................................................................12

TURN....................................................................................................................................13

Signaling/MediaProxyCombination........................................................................................14

ICE.......................................................................................................................................14

UsinganExternalB2BUA/MP......................................................................................................15

Summary...................................................................................................................................18

Acronyms..................................................................................................................................19

AboutDitechNetworks..............................................................................................................19

Page 3: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks �/20

Introduction

Thegoaloffar-endNATtraversalistoallowinboundandoutboundVoIPcallstosucceedinthehighestpossible

numberofcases,evenwhenoneorbothcallpartiesonthecallarebehindoneormoreaddress-translation-enabled

firewalls.Norequirementsonthesubscriber-premise’shardware,software,orfirewallshouldbepermitted–the

subscriber’sexperienceshouldbetosimplypluginaproperlyconfiguredVoIPphoneandstartmakingcalls.This

paperdiscussestheissuesthatmustbeconsideredandthesolutionsrequiredtoachievethisgoal.

Webeginbyexaminingtheeffectsoffirewallsintheirroleaspacketadmissioncontrollingpoints,andthenlookinto

themorecomplicatedissuesarisingfromNetworkAddressTranslation(NAT)andPortAddressTranslation(PAT).

Packet Admission Policy Problems

BeforediscussingtheissuesofNATandPAT,administratorsmustunderstandthatnetworkfirewallscreatemanyof

VoIP’sproblemswiththeirpacketadmissionpolicies.ThisisbecausefirewallsarethegatekeeperoftheUDPprotocol

whichisrequiredbyVoIP.Bydefault,firewallsaretypicallyconfiguredtobehaveinoneormoreofthefollowing

modes,listedinorderofrestrictiveness.

Packet Admission Policy Modes

1.AllowallUserDatagramProtocol(UDP)datagramstocomeinthroughthefirewall(Open).

2.AllowonlycertainhoststosendUDPinbound.

3.AllowcertainhoststosendUDPinboundonlyfromcertainports,andonlytocertaininsidehostsoncertainports.

4.AllowallexternalhoststosendinboundUDPtoanyinsidehost,providedthatthesametypeoftraffichasrecently

beenemittedoutboundfromanyinsidehost/port.ThisiscalledaFullConeNAT.

5.AllowanexternalhosttosendinboundUDPfromanyporttoaninsidehost,providedthatthesametype

oftraffichasrecentlybeenemittedoutboundfromanyinsidehost/porttothatexternalhost.Thisiscalleda

RestrictedConeNAT.

6.AllowanexternalhostandonlythatspecificexternalhosttosendinboundUDPusingthesameportpairtoan

insidehost.ThisiscalledaPort-restrictedConeorSymmetricNAT.Notethatthereisalsoafurtherdifference

betweenaPort-restrictedConeandSymmetricNATwhichrelatestotheuseofdifferentglobal-porttolocal

host-portbindingsfortrafficexchangesbetweenasingleinternalhosttodifferentexternalhosts.

7.AllowanexternalhosttosendinboundUDPtoaninsidehost,providedthatthesametypeoftraffic(host/port)

hasrecentlybeenemittedoutboundtoaportattheexternalhostthatislowerthan1024.Thisisamore

restrictivevariantofPort-restrictedConeorSymmetricNAT.

8.BehaveasaproxyserverthatonlyallowsinboundUDPtrafficfromspecialconfigurationsontheclients.

9.DenyallinboundUDPtrafficandresponses(Closed).

TheconceptofCPE-lessNAT/FirewalltraversalrestsonthepremisethatUDPresponsesfromatleastoneserveron

theoutsidenetworkmustbeallowedtopassthrough.

DifferentvendorsusedifferentterminologytodescribeModes4through7intheirfirewallconfigurations.Themost

commonnamesincludeStatefulInspection,AdaptiveSecurityAlgorithm,StatefulUDP“Connection”Cache,and

ReflexiveUDPAdmission.

Page 4: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks �/20

WewillusethetermReflexive UDP Admissiontodescribefirewallsthatallowanexternalhosttorespondsymmetri-

callywithinagivenperiodoftime.Wewillalsocallthistemporaryadmissionofresponsesapinhole.Mostfirewalls

supportReflexiveUDPAdmissionbydefault,butfirewallvendorsusuallydonotdisclosewhichtypeamongthe

abovemodesthatthedefaultbehaviorforUDPadmissionfallsinto.

Pinhole Timeout Thresholds

Additionally,mostfirewallvendorsdonotdisclosethelengthoftheinactivityperiodafterwhichadynamic

pinholeisclosed.Inourobservations,multipleinboundpacketsareusuallyacceptedfor30secondsto10minutes

afteranoutboundpackethasbeensent.

However,somefirewallsmayarbitrarilyclosethepinholes,whichhaltstheexternalentity’sabilitytosend

inboundcalls.

Signaling Asymmetry

SignalingasymmetryoccurswhenaclientatanIPandportaddressdeclaresadifferentIPaddressorportin

theViaand/orContactheadersthataredifferentfromtheIPaddressorportactuallyusedtoemitthatSIPsignal.

Forexample,considerthescenariowherethereisanexternalSessionInitiationProtocol(SIP)proxyserver(Px)

locatedat204.31.1.11listeningonUDPport5060.ASIPclient(C1)locatedat192.159.1.11behindanon-NAT

firewallsendsaUDPsignalfromtherandomlyassignedephemeralport12345tothePxportlocatedat5060.

Theclienthastheoptiontochooseaporttolistentoforresponsesandfuturerequests.If,intheSIPsignaling

packet,theclientdeclaresaVia:informationandContact:informationof192.159.1.11:12345(thesameasitsactual

addressandport),therewillbenoproblemsforfirewallsconfiguredtobehaveaccordingtoModes1through4as

previouslymentioned.However,thisgeneralrulemaybesubjecttotheproblemsdescribedbelow.

Client-Side Signaling Asymmetry

Client-sidesignalingasymmetryoccurswhenaclientdeclaresadifferentcontactportintheVia.

Inthisscenario,ifaclientdeclaresaVia:portthatisdifferentfromthesourceportusedtosendouttheinitial

outboundsignal(mostlikelyaREGISTER),thenfirewallsthatareconfiguredtobemorerestrictivethanMode3

willnotallowsuchresponsepacketstoreachtheclientatthedeclaredport.

Forexample,ifaclient(C1)locatedat192.159.1.11:12345sendsaREGISTERtotheSIPproxyat204.31.1.11:5060

withadeclaredVia:192.159.1.11:5060,thentheexpectationisfortheservertosendtheresponsetoaportother

thantheinitialephemeralport.Figure 1displaysaschematicofasuccessfulclient-sidesignalingasymmetry.

Figure 1: : Client-SideSignalingAsymmetry(Successful)

Page 5: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks �/20

Iftheserverrespondsbacktoport5060,itwillnotpassthroughthefirewall.Figure 2displaysaschematicofan

unsuccessfulclient-sidesignalingasymmetry.

Figure 2 : :Client-SideSignalingAsymmetry(Unsuccessful)

Server-Side Signaling Asymmetry

ThereareseveralwaysaSIPproxyserver(Px)cansendresponsesbacktotheclient(C1).Let’srevisittheinitial

outboundsignalfromtheaboveexample.TheclientlocatedatIPaddress192.159.1.11andport12345now

declaresintheVia:192.159.1.11:12345totheSIPproxylocatedat204.3.1.11:5060.

Theexternalservermayrespondinthefollowingways:

• RespondusingadifferentIPaddress:allowedonlybyMode1.

192.159.1.11:12345<-204.31.1.12:5060

• Respondusingadifferentsourceport:allowedonlybyModes1and2

192.159.1.11:12345<-204.31.1.11:54321

• Respondsymmetrically:allowedbyMode4andothermorelenientmodes

192.159.1.11:12345<-204.31.1.11:5060

Aport-restrictedorsymmetricfirewall(Mode4)furthermandatesthatPxmustsignalC1usingasourceportof5060.

Somefirewallsfeatureconfigurableswitchescalledporttriggeringorestablishedudp,whichallowanadministrator

toopenmultiplepinholesonfirewallsasaworkaroundtotheabovesignalingasymmetry.However,suchoptionsare

notpractical,astheuserwhohasthephonebehindthefirewallmaynothaveadministrativecontroloverthefire-

wall.Therefore,toassuresuccessfultraversalacrossfirewallsthatsupportdynamicUDPadmission,itisrecommended

thatboththeinsideandoutsideentitiesusethesameporttosendandreceiveacertaintypeoftraffic.

Outbound Calls and 2-Way Media

AtypicaloutboundSIPcallinvolvesacallersignalingaproxywithanINVITE.TheproxythenrelaystheINVITEtothe

callee.TheSessionDescriptionProtocol(SDP)informationwithintheINVITEmessagetellsthecalleewheretosend

themedia.Whenthecallisaccepted,thecalleesendsa200OKmessagewithSDPinformationthattellsthecaller

wheretosendthemedia.

Page 6: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks �/20

Iftheoutboundcallerdoesnotsendthefirstmediastreamofthecall,thecallerwillonlybeabletohearmediafrom

thecalleeifhe/sheisbehindafirewallusingModes1through3.ThisisbecausearestrictedconeNATwillnotallow

ahost(thecallee)–towhomthecallerhasnotrecentlysentapacket–tosendanyUDPinboundacrossthefirewall.

ForthecalltobesuccessfulwhenthecallerisbehindafirewallusingModes1through6,boththecallerandcallee

shouldsendmediaonthesameportastheydeclareintheSDPthattheywillbelisteningformedia.

Figure 3belowdisplaysanexampleofthisprocess.

Inthisfigure,thecallerlocatedat192.159.1.11:16384sendsoutanINVITEtothecalleewithSDPinformation

informingthecalleewheretosendmedia.Thecalleerespondsbysendinga200OKwithitsownSDPinformation,

afterwhichacallisestablishedbetweenthecaller’sportat16384andthecallee’sportat8000.

Figure 3 : :OutboundCallsand2-WayMedia

Inthisexample,mediaisexchangedsymmetricallybetweenthecallerandcallee.Thissatisfiesthepacketadmission

requirementsofthemorerestrictivefirewalls,aslongasthefirewallsthemselvesareconfiguredtosupportReflexive

UDPAdmission.

If,atanytimeduringthecall,thecallerbehindthefirewallstopssendingmediaoutboundforasufficientamountof

time,thereisnoguaranteethatthefirewallwillcontinuetoadmitincomingRealTimeProtocol(RTP)mediastreams.

ThisalsoappliestoRealTimeControlProtocol(RTCP)packets.Itislikelythatthefirewallwillnotadmitaninbound

RTCPpacketunlessanoutboundRTCPpackethasbeenemittedfromthecallertothecallee.Ifsufficienttimehas

elapsedbeforethenextRTCPexchange,thereisapossibilitythatthepinholeforincomingRTCPwillbeclosed,and

theexternalcalleesendingtheRTCPpacketmaygetamessagefromthefirewallthattheInternetControlMessage

Protocol(ICMP)destinationisunreachable.

REGISTER Packet and Inbound Calls

MostSIPdeploymentsaresetupinsuchawaythatSIPphonessendaREGISTERpacketouttoaRegistrarProxy

uponstartup.Theregistersignal,whenauthenticatedandacceptedbytheRegistrarProxy,informsthecallerwhere

thecalleecanbereachedforfutureincomingrequests.Thiscoincidentallyopensupapinholeacrossthefirewallfor

incomingrequeststobedeliveredtotheclient.

Page 7: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 7/20

Asdiscussedearlier,thefirewallmayclosethepinholewhenaperiodofinactivityhaspassed.Commonmeasures

takentokeepthefirewallpinholeopenincludethefollowing:

• ConfiguringtheSIPProxytosenddummykeep-alivepacketstotheclient.

• ConfiguringtheSIPclientstosenddummykeep-alivepacketstotheSIPproxy.

• ConfiguringtheSIPclientstore-registerwiththeSIPproxyapproximatelyevery30seconds.

Unfortunately,dummypacketsmaybeineffectiveintheNATcasestobediscussedlaterinthispaper,andincreasing

thefrequencyofre-registrationoftencarriesthepenaltyofoverwhelmingtheproxyregistrationdatabase.

Network and Port Translation Problems

NetworkAddressTranslation(NAT)addsfurthercomplicationstoSIP.ThisisbecauseSIPsignalingreliesonthe

IPaddressesandportnumberscontainedinthesignalingmessagepayload,andthispayloadcanbeimproperly

translatedbyNATenabledfirewalls.

Figure 4belowdisplaysanexampleofNATintroducedcomplications.Inthisexampletheinsideclient(C1)sendsa

SIPrequestpackettoanoutsideSIPproxy(Px)viaaNAT(Nx).

Notethatinthispaper,welimitourdiscussionofNATtothemostcomplex(andmostcommon)situation,wherethe

firewallexhibitsdynamicUDPadmissionandwherenostaticNATorPATforwardingisenabled.

Figure 4 : :NATComplications

IftheSIPproxy(Px)weretofollowtheembeddedViainrespondingtotheoriginalSIPmessage,thepacketwould

havebeensentto192.168.1.100,whichisunreachableontheInternet.

IftheSIPproxy(Px)weretosendaresponseaccordingtothesameUDPsourceaddress,itislikelythattheresponse

messagewillreachtheclient.

Page 8: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks �/20

However,hereliestheconflictwhenthepacketsentbytheclientisaREGISTERmessage.Figure 5below

displaystheconflict.

Figure 5 : :REGISTERMessage-Conflict

AccordingtotheSIPspecification,theproxyshouldenterintoitsregistrartablethatclientC1isreachableat

192.168.1.100,port5060.Obviously,thisaddresswillnotbereachable.Forpracticalreasons,itshouldhaveentered

192.159.1.11:1024instead,aslongastheclientsignalssymmetrically(listensonport5060).Unfortunately,bydoing

this,theproxydeviatesfromtheSIPspecification.

NAT Port Contention and Port Rotation

MostNATfirewallsaredeployedinPortAddressProtocol(PAT)modebydefault,wheremanyinternalclientsshare

thesameglobal(external)IPaddressofthefirewall.

ConsiderthecasewheretwoSIPclients(C1andC2)arelocatedintheinternalnetworkandsendREGISTER

messagestothesameSIPproxy(Px)outside.ClientC1isat192.168.1.100andclientC2isat192.168.1.101.

Figure 6belowdisplaysaschematicofthisconfiguration.

Figure 6 : :NATPortContention/Rotation

Page 9: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks �/20

IftheNATdoesnottranslateportsbydefault,thefirstclient(C1)islikelytogetasourceportontheglobalIP

addressthatisidenticaltotheoriginalsourceportof5060.Ifthereisasecondhostontheinsideusingasourceport

of5060totalktotheSIPproxyatPx,thefirewallwillassignitarandomephemeralport(suchas192.159.11:1024).

However,thereisaphenomenonsimilartomusicalchairsthatislikelytohappen.Ifthefirsttranslationslotfor

192.168.1.100everexpiresandapacketissentfromC2ataddress192.168.1.101:5060,thenC2willlikelygetthe

translationslotof192.159.1.1:5060,andC1willgetanewtranslationslotof192.159.1.11:1025.

SowhathappenstoincomingcallstoC1?IftheSIPproxy(Px)“remembers”C1isat192.159.1.1:5060basedonthe

initialregistration,thenanincomingINVITEwillbesenttothewrongphoneandC2willlikelystartringing,oreven

rejectthecallbecausetheINVITEwouldcarryarequestURIof192.168.1.100:5060,andnot192.168.1.101:5060.

NAT and Media

Let’sexaminetheproblemwithSDPandmedia.Considerthecasewhereacallerbehindafirewallcallsacallee

outsidethefirewall.Inthisscenario,thecallerislocatedbehindthefirewallat192.159.1.11:16384.Figure 7below

displaysaschematicofthisconfiguration.

Figure 7 : :NATandMedia

SincethecalleereceivestheINVITEfromtheproxy,thecalleewillnothaveanyideawhatthefirewallglobalIP

addressofthecallerwouldbe,nottomentionthecorrectporttosendto.TheSDPinformationcontainedinside

theINVITEmessagesimplycannotbeused.

AcallerbehindaNATfirewallmaybeabletolearnwhatitstranslatedglobalIPaddressisaheadoftime.Inthis

outboundcase,theinitialINVITEcontainsthecorrectIPaddress.ConsiderthecasewheretheuserbehindaNAT

192.159.1.11alreadyknowsaheadoftimewhatthetranslatedaddresswillbe,andconfiguresthephonetosend

SDPinformationtocontaintheglobalIP(Figure 8 onpage10).

Page 10: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 10/20

Figure 8 : :NATandMedia-SecondExample

TheINVITErequeststhecalleetosendmediato192.159.1.11:16384,andthecallerstartslisteningonport16384for

incomingmedia.

NATfirewalls(withtheexceptionofFullConeNATs)disallowthecallee’smediapacketscominginbound.Thisisalso

anissuewithporttranslation.Forexample,whenthecallersendsmediaviaaNATtoacallee,theUDPstatecreated

intheNATmayhaveaportthatdiffersfromtheUDPportusedbythecaller.

TheSDPinformationembeddedintheoutboundINVITEhasaUDPportdeclared.Thisistheportfromwhichthe

callerwillsendmediaifitsendsandreceivesRTPmediasymmetrically.However,unlessthefirewallisguaranteed

nottoperformanyporttranslation,itisunlikelythatanincomingstreamfromthecalleetotheNATport(inour

example,portnumber16384)willbetranslatedandsentinboundtocalleeport16384.

IftheNATtypeismorerestrictivethanaFullCone,thequestionbecomeswhatthecallershouldsendacrossthe

firewalltocreatetheUDPstateentry(orpinhole)onthefirewall,suchthatincomingmediawillreachport16384.

IfthecallerknowsaheadoftimethatthecalleeisnotbehindaNAT,anditsSDPcanbetrusted,thenthecallercan

sendmediaassoonasa200OKisreceived(seeFigure 9onpage11).

Page 11: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 11/20

Figure 9 : :CallerAwareCalleeNotBehindNAT

Iftheexternalcalleeweretodisregardthecaller’sSDPdeclaredintheINVITE,butsendmediasymmetricallytothe

calleronceithasreceivedamediapacketfromthecaller,then2-waymediashouldbeestablished.However,wehave

notseenaSIPphoneinproductionthatiscapableofthis.

Furthermore,inthecasewherebothcallerandcalleearebehindtheirrespectivefirewalls,boththecallerandcallee

willbeinlimbo,waitingforeachothertobethefirsttosendmedia.

Common Attempts to Solve the Problems

ThefollowingsectiondescribesthecommonmeasuresusedtoachieveCPE-lessfar-endNATtraversalforSIP.With

theexceptionofTransmissionControlProtocol(TCP)signalingandUPnP,themethodsdescribedtakeadvantageof

signalingandmediasymmetryonalmostallnewerphones,andReflexiveUDPAdmissiononmostfirewallsintheir

actualdeployedconfiguration.

Using TCP

UsingTCPforsignalingandconfiguringtheproxy(wherepossible)toignoremismatchingViaandContactheaders

causedbyNATstoacertainextentcanwork.However,toensurethatinboundcallscanreachclientsbehindfirewalls,

persistentTCPconnectionsmustbemadewiththeproxy,whichdramaticallyreducesscalabilityandcreatesa

significantamountofnetworkoverhead.Furthermore,mostNATfirewallshaveTCPidletimeouts,mandatingthe

useofkeep-alivepacketsacrosstheTCPconnection.NotethatTCPonlyaddressessignaling,becauseRTPandRTCP

arestilltransmittedinUDP.

UPnP

UniversalPlugandPlay(UPnP)clientstrytosignaltheNATfirewalltopre-allocatenumerousUDPportstoallowboth

incomingsignalandmedia.Inpractice,thereisoftenconfusionintheallocationoftheseportswhenmorethanone

clienttriestoopenthesamerangeofUDPports.Sincealargepercentageoffirewallsarenotconfiguredtohave

UPnPenabled,onecannotrelyonUPnPtowork,especiallywhenusersmaynotknowwhetherthefirewallthey

arebehindisactuallyUPnPcompatible.

Page 12: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 12/20

STUN

SomeIPphonevendorsareimplementingSimpleTraversalofUDPthroughNAT(STUN),whichisinIETFDraftstage

(RFC3489).STUNisaprotocolthatletsthephonequeryanexternalservertovalidateitsexternalIPaddress/port.

Unfortunately,STUNdoesnotworkinthecommoncorporatefirewallexampleofasymmetricNAT.

Inthisexamplebelow(seeFigure 10),thecallersendsasingleSTUNquerytogetitsRTPport(abridgedforthe

sakeofsimplicity),whichistranslatedfrom16384to1024.

Figure 10 : :STUNPortTranslation

Whenmakinganoutboundcall,thecaller(C1)sendsanINVITEto(C2)usingtheIPaddressandportinformationit

receivedfromtheSTUNqueries(Figure 11).

Figure 11 : : STUNPortUsage

However,whenthetimecomesforthecallertosendmediatothecallee,theNATassignsanewportallocation.This

maybeduetothefactthatthefirewallchoosesadifferentbindingforadifferenthost(STUNservervs.callee),oritis

adifferentbindingduetoadifferentdestinationport(3478vs.8000inthisexample).

Page 13: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 1�/20

Figure 12below,displaysaschematicofthisexample.Whenthecalleetriestosendmediatoport1024onthe

firewallbasedontheSDPinformation,itgetsblocked.

Figure 12 : :BlockedMedia

Furthermore,thereisnotellingwhethertheexternalhostwillsendmediasymmetrically.Manymediaserversfor

voicemail,IVR,andconferencedonotsendandreceivemediaonthesameport.Thiscreatesamediaasymmetry

forwhichevenPort-restrictedConefirewallswillnotwork.

NewerphonesoftenexecuteaSTUN“test”tonotifytheuserwhattypeofNATfirewallthephoneisbehind.

However,sinceNATbindingscanchangeorexpirewithoutwarning,aSTUN-enabledphonebehindaNATfirewall

shouldregularlyreconfirmitsglobaladdressandportswiththeSTUNservers,andpreferablyrightbeforeitsendsa

requestsignal.Unfortunately,thiscarriesthepenaltyofaddingloadtothenetwork.

Inrarecases,aRestrictedConeNATmayexhibitthebehaviorofaSymmetricNAT.Thesesymptomsareobservable

whenaphonefrequentlyre-registersfromdifferentglobalsourceports.Thismaybeduetotheinadvertentclearing

ofthe“translationtable”forconfigurationchangesthatmandatetherestartingofthefirewall,crashes,orsimplya

failuretofollowthetranslationtimeoutsbasedoninactivity.

Ingeneral,STUNcanworkwell,butonlywhenthefollowingconfigurationexists:

• TheSTUNclientisbehindaNATthatislessrestrictivethanaPort-restrictedCone,and

• Thesignalingproxysignalssymmetrically,and

• Theendpoint,iflocatedontheexternalnetwork,emits/receivesRTPsymmetrically, ortheotherendpointisa

STUNclient.

TURN

AsignificantsupplementtoSTUNthatutilizesanexternally-hostedMediaProxytodealwithsymmetricNATsis

TraversalUsingRelayNAT(TURN).ThegoalofTURNistoenablecallstopassthroughsymmetricNATs.

Page 14: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 1�/20

EndpointscouldbeequippedwiththeintelligencetonegotiatewiththeTURNservertoallocateandsendmedia

toaglobally-routablemediarelay.InsteadofsendingmediabasedonSDPinformation,itrelaysmediaforeachcall

symmetrically,usingthesamesourceportonwhichitlistensforincomingmedia.

Amajorcriticismofthisapproachistheamountofbandwidthwastageandlatencyinducedbyroutingallmediato

acentralrendezvouslocation,andsubsequently,totheotherparty.Callsbetweentwoneighboringendpointsoften

findtheirmediaroutedoutthefirewallandbackunnecessarily.

Signaling/Media Proxy Combination

TURNrequiresintelligencebuiltintotheendpointstosignalaTURNserver.Analternativeapproachistohavean

externalMediaProxythatoperatesinconjunctionwithaRegistrar/SignalingProxythatmodifiesSDPascallsignals

passthrough.

Thisapproachdoesnotrequireendpointstohavetheintelligencetoperformanyglobaladdressdiscoveryorpre-call

signalingwithaTURNserver.AslongastheendpointssendandreceivemediasymmetricallyandtheNATsinvolved

supportreflexiveUDPadmission,thereshouldbenotroublegettingcallsthrough.

However,thisapproachsuffersthesamedrawbackastheSTUN/TURNcombinationintermsofbandwidthefficiency

andscalability,andtheSIPproxyoftenperformsunnecessaryre-routingofmediabetweenclientsthatarenotbehind

firewallsorNATs.

ICE

InteractiveConnectivityEstablishment(ICE)isamethodthattriestobuildintelligenceintoendpointssothatthey

canperformroutediscovery,pathoptimization,andevenverifymediaflowbeforeacallisdeemedtobeestablished.

PriortosendinganINVITE,thecallerperformsasequenceofstepstocharacterizethefirewallthatitisbehind:

• Obtainsaddressesofallusableinterfaces(local,VPN)

• CheckstheresultsfromSTUN

• Ifneeded,negotiatesaportwiththeTURNserver

Afterwards,thecallersendsalistofavailableIPaddresses/portsintheINVITEtotheproxy.

AssoonasthecalleegetstheINVITE,itfollowsasimilarsetofstepsasdidthecaller.Next,itattemptstosendSTUN

queriestothecallertoseeifitispossibletodirectlysendmediatoanyoftheIPaddressesitpresentedintheINVITE.

Finally,thecalleepickstheaddressofhighestpreferenceintheINVITEtowhichthecalleecanconfidentlysendmedia.

ThisapproachiscompatiblewithmostknownfirewallsthatsupportUDP.Inadditiontoworkingwithalltypesof

NATsthatsupportreflexiveUDPadmission,italsoworkswiththeveryrestrictivefirewallsthataredeliberately

configuredtoonlyallowinternalhoststoconverseusingUDPwithoneortwohostsontheoutside.However,for

ICEtoworkproperly,bothcallerandcalleemustsupportICE,andthereshouldreadilybeaSTUNandTURNserver

available.Forthisreason,itshouldbedeployedonlyinahomogeneous,controlledenvironment.Furthermore,it

islikelythatthecallsetupwillbedelayedbecauseofthestepsinvolvedinmediapathdiscoverybyboththecaller

andcallee.

Finally,withtheendpointsadvertisingtheirowninternalIPaddresses,ICEmaynotmeetthetopologyhiding

requirementsofsecurity-focusedenvironments.

Page 15: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 1�/20

Using an External B2BUA/MP

Theapproachesdiscussedthusfarinthispapercanonlysolveselectedproblemssomeofthetime.Furthermore,

theyoftenrequireadditionalintelligenceontheendpoints,whichmaynotalwaysbeavailable.

Fortunately,anapproachhasbeendiscoveredthatworksinvirtuallyallsituationsthatdoesnotrequireanyadditional

customer-premiseequipment,software,orfirewallconfiguration.TheresultofapplyingthisapproachisthatVoIP

signalingandmediastreamscanbemadetotraverseanarbitrarynumberof(possiblynested)NAT,PAT,andfirewall

devices,usinganystandards-compliantendpoint.Thisapproachhastheaddedbenefitthatinalmostallcases,no

additionalmediaworkloadorlatencyisintroduced,sincethemediastilltraveldirectlyfromcallertocallee,and

viceversa.

ThisapproachinvolvestheuseofaSessionBorderController(SBC)thatcontainsaSIPBack-to-BackUserAgentwith

anembeddedMediaProxy(B2BUA/MP).TheB2BUA/MPislocatedintheserviceprovider’snetwork,fromwhereit

canseeandreachtheglobalIPaddressesandportnumbersofallcallparticipants.Theendpointsinacallareset

uptoeitherregisterthroughtheB2BUA/MP,ortouseitastheiroutboundproxy(asperIETFRFC3261).Thejob

oftheB2BUA/MPistoacceptcallsignalingandmediastreamsfromendpointslocatedbehindNATdevices,andto

“sanitize”thosestreamssothattheycanbesentfurtheroutontotheglobalInternet.Itisnotnecessaryforboth

endpointstobebehindthesameB2BUA/MP.Indeed,oneendpointcanbebehindoneandtheotherendpoint

behindanother,oroneendpointcanbebehindonewhiletheotherusessomeothermeanstodealwithitsownNAT

problems.Oneofthemajoradvantagesofthisapproachisthatitdoesnotrequireanyspecialdeviceorconfiguration

tobepresentatbothendsofacall.

Thefollowingexample(Figure 13below)showshowaB2BUA,configuredastheoutboundproxyoftheclient,can

functionasafar-endNATtraversaldevice.

Figure 13 : :B2BUAasaNATTraversalDevice

TheregistrarproxynowhastheuserlocationinformationofC1attheB2BUA.Whenproperlyimplemented,the

B2BUAdoesnothavetokeepastaticallyprovisioneddatabaseofusers,nordoestheproxyneedtobestatically

configuredwithuserlocationspointingattheB2BUA.

Page 16: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 1�/20

ToensurethatuserC1isalwaysreachableincaseofinboundcalls,theB2BUAusesvarioustypesofSIPsignalsto

encouragetheclientC1toregularlysendSIPtraffictotheB2BUA.ThisflowofSIPsignalsatregularintervalshelps

maintainthepinholeatthefirewall.IncaseofanunexpectedpinholeclosureorchangeinUDPstatebrought

aboutbyfirewallanomalies,this“heartbeat”trafficservestoinformtheB2BUAoftheclient’snewgloballocation.

Topreventtheproxyfrombeingoverwhelmedbythisheartbeattraffic,thesignalsarenotpassedtotheproxy

unnecessarily.AsanadditionalmeasuretodealwithclientsthatdonotobeytherequestbytheB2BUAtosend

outboundmessages,theB2BUAinitiatesSIPmessagestoclientsperiodicallytoverifytheirrespectivelocations.

Whenproperlyimplemented,allthesignalsmentionedaboveshouldbegenericSIPsignalsthatshouldnotcause

anyproblemstoanySIPendpoints.

TheB2BUAalwaysusesthesameporttocommunicatewiththeclient,whichmakesitcompatiblewithsymmetric

NATs.UnlikeUPnP,wheretheclientopensmultipleportsacrossthefirewallformultipleexternalhosts,thereisno

requirementfortheclienttoopenadditionalpinholesacrossthefirewall.

Whenacallisinitiated,theB2BUAmodifiesthesignals,informingboththecallerandcalleetosendtheirmedia

topre-allocatedportsonaMediaProxy,oftenconfiguredtorunonthesamemachineastheB2BUA.Atregular

intervals,theB2BUAusesstandards-compliantSIPsignalstoverifythatbothcallerandcalleearestillonthecall.

Inthemostchallengingscenario,bothcallerandcalleeareeachbehindtheirownsymmetricNATs.SincetheMedia

Proxyisengagedatthestartofthecall,bothpartiesreceivemediafromeachother,providedthateachsidehassent

atleastoneRTPpacket.Ifnofurtheractionistakentooptimizethecall,thebehavioroftheB2BUAissimilartothe

Signaling/MediaProxycombinationmentionedearlierinthisdocument,havingthesamedrawbacksofmedialatency

andbandwidthwastage.

UnlessonepartyonthecallisbehindasymmetricNATwithfrequentporttranslationchanges,itispossibleto

re-directthemediaduringthemiddleofacall,wherethecallersendsthemediatothecorrectportonthefirewall

thathidesthecallee,andviceversa.ItisalsopossiblefortheB2BUAtousestandards-compliantSIPsignalsto

characterizethetypeofNATfirewallinfrontofeachpartyonthecall.Thisisdonebyinspectingthecharacteristics

ofthemediaflowaftereachofthoseNAT-characterizedsignalshasbeensent.ThistechniqueiscalledMediaPath

Optimization(MPO).Figure 14onpage17displaysaschematicoftheprocessfortheB2BUA/MP.

Page 17: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 17/20

Figure 14 : :B2BUA/MPProcess

Figure 14displaysthefollowingstepsintheB2BUA/MPprocess:

1. AssumingcalleeC2hasregistered,callerC1sendsanINVITE.

2. TheSIPproxyserver(Px)locatesC2attheB2BUA.

3. TheB2BUAsendsanINVITEtoC2’sfirewall.Notethatthesignalingprocessthatestablishesthecallhas

beenomittedhere.

4. Theinitialmediaflowhasboththecallerandcalleesendingmediatothemediaproxy.

5. TheB2BUAnowstartsNATcharacterizationofthefirewallsonbothsides.

6. TheB2BUAsendssignalstobothendpoints,tellingthemtosendthemediatospecificportsontheother

party’sfirewall.

7.TheB2BUAsuccessfullyremovesitselffromthemediapath,butitstillmaintainscontrolofcallsignaling.

Thekeydifferentiatorofaport-translatingsymmetricNATfromotherNATtypesisthatadifferentglobal-to-local

port-mappingisusedifthesameinternalhostsendsapacketwiththesamesourceaddressandport,buttoa

differentdestinationhostordestinationport.ByobservingthechangesinmediabehaviorwitheverySIPsignal

senttoeachpartyonthecall,theMediaProxycandeterminewhetheraclientisbehindaport-translatingsymmetric

NAT.IfeitherpartyisbehindsuchaNAT,theMediaProxymustcontinuetoproxythemediaforthecall.Fortunately,

thepercentageofsymmetricNATsdeployedremainsrelativelysmall,especiallyinSmallOffice/HomeOffice(SOHO)

environments.AsidefromNATcharacterization,SIPsignalsgeneratedbytheB2BUAmediapathoptimization

sequencealsohelptodeterminewhetherbothclientsonthecallaretolerantofmediaredirection.

Page 18: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 1�/20

SinceNATcharacterizationisperformedafterthecallhasbeensetupandmediaisbeingreceivedbybothparties,

extremecaremustbetakentoavoidlossofmediaduringtheprocedure.TheMediaProxyshouldnotdisengageitself

untilacertaintimehaselapsedaftermediapathoptimizationhascompleted,andbothclientsaresendingmediato

theotherparty’srespectiveglobaladdressandport.IftheMediaProxyeverdetectsanundesirablebehavioronthe

partoftheclientorfirewall,SIPsignalsshouldbegeneratedbytheB2BUAtoinformtheclientstorevertbacktothe

originalmediapath.

Additionally,thereareotherissuestobeconsideredwhenmediapathoptimizationisexecuted.TheB2BUAcannot

simplyattempttogloballyoptimizeallcalls.Someuseragentsdonotreactproperlytomediaredirectingandwillnot

sendmediatotheredirecteddestination.

ThereisalsotheissueofwhethertohavethepartieswhoareapparentlybehindthesameNAPTaddresssend

mediatotherespectiveportsontheNATglobaladdress,orwhethertheyshouldsendmedialocallytoeachother.

AsignificantpercentageofNATswillnotrelay“hairpinmedia”usingtheirglobalIPaddresses.Thatis,twohostson

theinternalsideoftheNATmaynottalktoeachotherbyusingtheglobalIPaddressoftheNAT.Ontheotherhand,

redirectingtheRTPflowtoeachparty’slocaladdressmaynotworkwellinthecasewherethereisonepartybehind

asecondlevelofcascadedNATcallingapartylocatedinadifferentcascadinglevel.Suchcasesmandatedisabling

mediapathoptimizationforcertainglobaladdresses,orusingslavemediarendezvouspointsstrategicallylocated

tominimizebandwidthwastage.

InadditiontoresolvingtheNATtraversalissues,anSBCwithaB2BUAcanprovideotherbenefitsthatareoften

criticaltotheVoIPnetwork,suchas:

• Topologyhiding

• ProtectingservicefromDOSattacks

• EnforcingQoSpolicies

• Ensuringend-to-endinteroperability

• Billing

• Per-sessiontroubleshooting

• Lawfulintercept

Summary

MostprovidersofIPtelephonyservicesbelievethattheexperienceofausershouldmirrortheeaseofuseand

ubiquitousavailabilityofthePublicSwitchedTelephoneNetwork(PSTN).Indeed,inmanycases,theeconomicsof

providingservicerequirethatthings“simplywork”sothatcustomersupportexpensesarekepttoaminimum.Given

thecomplexityoftoday’sNATandfirewallprotectednetworks–bothinresidentialandenterpriseenvironments

–thiskindofubiquitousreliabilityforVoIPcanonlybesuccessfullyprovidedwithsomehelpfromaNATtraversal

system.Again,drivenmostlybyeconomics,suchasystemmustnotrequireanyspecialhardwareorsoftwareonthe

users’premises,andmustnotrequireeithertheserviceproviderortheusertohaveanyspecialknowledgeofthe

topologyofthenetwork(orhowitsNATandfirewallcomponentsaretobeconfigured).ThegoalofaNATtraversal

systemforreal-worlddeploymentmustthereforebetosolveusers’NATandfirewallproblemsremotely,andfrom

theserviceprovider’snetwork.

Page 19: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

Copyright © 2007 Ditech Networks 1�/20

Manysolutionsinvolvingremotely-locatedNAThelperappliancessuchasSTUN,TURN,ICE,andUPnPhavebeenpro-

posed,buteachcanreasonablybedeployedonlyinasubsetofsituationsthatistoosmalltobeofpracticalusefora

ubiquitousservice.Ontheotherhand,theBack-to-BackUserAgentapproachwithitsembeddedMediaProxyworks

invirtuallyallsituations,andmeetsthegoalofnotrequiringanyspecialand/orcomplexuserpremiseinstallation.

Acronyms

B2BUA/MP Back-to-BackUserAgentandMediaProxy ICE InteractiveConnectivityEstablishment

ICMP InternetControlMessageProtocol IP InternetProtocol

NAT NetworkAddressTranslation PAT PortAddressTranslation

PSTN PublicSwitchedTelephoneNetwork RTCP RealTimeControlProtocol

RTP RealTimeProtocol SDP SessionDescriptionProtocol

SIP SessionInitiationProtocol TCP TransmissionControlProtocol

UDP UserDatagramProtocol VOIP VoiceoverIP

About Ditech Networks

DitechNetworksisaglobaltelecommunicationsequipmentsupplierforcommunicationsnetworks.DitechNetworks’

voiceprocessingproductsservetheneedsofmobileandwire-lineoperatorsforcircuit-andpacket-basednetworks.

Ditechproductsincludehigh-capacityvoiceenhancementandechocancellersolutionsthatutilizeadvancedsoftware

anddigitalsignalprocessor(DSP)technology.ThiscombinationofsoftwareandhardwareallowsDitechNetworksto

deliverVoiceQualityAssurance(VQA™)technology,arobustandcost-effectivesolutionforvoiceenhancementthat

includesbothnoisereductionandechocancellationtoprovideimprovedsoundqualityoncallsmadeoverwireless

networks.DitechNetworks’VoIPproductscombineVQAtechnologywithpacketvoiceprocessingandsecurity

capabilitiestoenablecarrierstodeployend-to-endVoIPservicesacrossnetworksecurityboundarieswithout

requiringnetworkre-architecting.Ditech(Nasdaq:DITC)isheadquarteredinMountainView,California,USA.

Page 20: Practical Far-End NAT Traversal for VoIP Whitepaper PDF

Practical Far-End NAT Traversal for VoIP

20/20

Corporate Headquarters

US Sales – West

DitechNetworks825EastMiddlefieldRd.MountainView,CA94043USA1-800-234-0884(TollFree)1-650-623-1300(Direct)1-650-564-9599(Fax)[email protected]

US Sales Office – East and Central

DitechNetworks8360GreensboroDr.McLean,VA22102USA1-800-234-0884(TollFree)1-650-623-1300(Direct)1-650-564-9599(Fax)[email protected]

Canada Sales Office

DitechNetworks2275LakeshoreBlvdWest,Suite500Toronto,ONM8V3Y3Canada1-416-255-7776(Phone)[email protected]

Mexico Sales Office

DitechNetworksTorcuatoTasso245-6o.PisoCol.PolancoMéxico,D.F.C.P.11570México+52(55)5254-5422(Main)+52(55)5350-8679(Sales)[email protected]

Brazil Sales Office

DitechNetworksAlamedaAraguaia,933AlphavilleBarueri,SP06455-000Brazil+55(11)4208-6266(Main)+55(21)3521-5543(Sales)[email protected]@ditechnetworks.com

China Sales Office

DitechNetworksUnit3010,No.500XiangyangSouthRoadXuhuiDistrictShanghai200031PRC+86(21)54560305(Phone)[email protected]

South-East Asia Sales Office

DitechNetworksLippoPlaza3rdFloorJl.Jend.SudirmanKav.25Jakarta12920Indonesia+62(21)52913780(Phone)+62(21)5221977(Fax)[email protected]

South Asia Sales Office

DitechNetworksNo.8/11,SarvapriyaViharNewDelhi–110016India+919810372555(Phone)[email protected]

Middle East/Africa Sales Office

DitechNetworks21El-FawakehSt.,3rdFloorDokki,Giza12311Egypt+202336-5100(Phone)+202761-8964(Fax)[email protected]

Spain Sales Office

DitechNetworksTorresQuevedo,1–(P.T.M.)28760TresCantos–MadridSpain+34(91)8037444(Main)+34(91)8292690(Sales)[email protected]@ditechnetworks.com

Copyright © 2007 Ditech Networks. All rights reserved. VQA is a trademark of Ditech Networks. All other brands are the property of their respective owners. Specifications may change without notice. This document was last revised 02/07.