| WHI T E PAP E R |

Practical Far-End
NAT Traversal for VoIP
March 2006
Practical Far-End NAT Traversal for VoIP
Contents
Cop,||| 2007 0|ec| Newo||s 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
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 3/20
Introduction
Thegoaloffar-endNATtraversalistoallowinboundandoutboundVoIPcallstosucceedinthehighestpossible
numberofcases,evenwhenoneorbothcallpartiesonthecallarebehindoneormoreaddress-translation-enabled
frewalls.Norequirementsonthesubscriber-premiseshardware,software,orfrewallshouldbepermittedthe
subscribersexperienceshouldbetosimplypluginaproperlyconfguredVoIPphoneandstartmakingcalls.This
paperdiscussestheissuesthatmustbeconsideredandthesolutionsrequiredtoachievethisgoal.
Webeginbyexaminingtheeffectsoffrewallsintheirroleaspacketadmissioncontrollingpoints,andthenlookinto
themorecomplicatedissuesarisingfromNetworkAddressTranslation(NAT)andPortAddressTranslation(PAT).
Packet Admission Policy Problems
BeforediscussingtheissuesofNATandPAT,administratorsmustunderstandthatnetworkfrewallscreatemanyof
VoIPsproblemswiththeirpacketadmissionpolicies.ThisisbecausefrewallsarethegatekeeperoftheUDPprotocol
whichisrequiredbyVoIP.Bydefault,frewallsaretypicallyconfguredtobehaveinoneormoreofthefollowing
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.
DifferentvendorsusedifferentterminologytodescribeModes4through7intheirfrewallconfgurations.Themost
commonnamesincludeStatefulInspection,AdaptiveSecurityAlgorithm,StatefulUDPConnectionCache,and
RefexiveUDPAdmission.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 4/20
WewillusethetermRefexive UDP Admissiontodescribefrewallsthatallowanexternalhosttorespondsymmetri-
callywithinagivenperiodoftime.Wewillalsocallthistemporaryadmissionofresponsesapinhole.Mostfrewalls
supportRefexiveUDPAdmissionbydefault,butfrewallvendorsusuallydonotdisclosewhichtypeamongthe
abovemodesthatthedefaultbehaviorforUDPadmissionfallsinto.
Pinhole Timeout Thresholds
Additionally,mostfrewallvendorsdonotdisclosethelengthoftheinactivityperiodafterwhichadynamic
pinholeisclosed.Inourobservations,multipleinboundpacketsareusuallyacceptedfor30secondsto10minutes
afteranoutboundpackethasbeensent.
However,somefrewallsmayarbitrarilyclosethepinholes,whichhaltstheexternalentitysabilitytosend
inboundcalls.
Signaling Asymmetry
SignalingasymmetryoccurswhenaclientatanIPandportaddressdeclaresadifferentIPaddressorportin
theViaand/orContactheadersthataredifferentfromtheIPaddressorportactuallyusedtoemitthatSIPsignal.
Forexample,considerthescenariowherethereisanexternalSessionInitiationProtocol(SIP)proxyserver(Px)
locatedat204.31.1.11listeningonUDPport5060.ASIPclient(C1)locatedat192.159.1.11behindanon-NAT
frewallsendsaUDPsignalfromtherandomlyassignedephemeralport12345tothePxportlocatedat5060.
Theclienthastheoptiontochooseaporttolistentoforresponsesandfuturerequests.If,intheSIPsignaling
packet,theclientdeclaresaVia:informationandContact:informationof192.159.1.11:12345(thesameasitsactual
addressandport),therewillbenoproblemsforfrewallsconfguredtobehaveaccordingtoModes1through4as
previouslymentioned.However,thisgeneralrulemaybesubjecttotheproblemsdescribedbelow.
Client-Side Signaling Asymmetry
Client-sidesignalingasymmetryoccurswhenaclientdeclaresadifferentcontactportintheVia.
Inthisscenario,ifaclientdeclaresaVia:portthatisdifferentfromthesourceportusedtosendouttheinitial
outboundsignal(mostlikelyaREGISTER),thenfrewallsthatareconfguredtobemorerestrictivethanMode3
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)
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 5/20
Iftheserverrespondsbacktoport5060,itwillnotpassthroughthefrewall.Figure 2displaysaschematicofan
unsuccessfulclient-sidesignalingasymmetry.
Figure 2 : :Client-SideSignalingAsymmetry(Unsuccessful)
Server-Side Signaling Asymmetry
ThereareseveralwaysaSIPproxyserver(Px)cansendresponsesbacktotheclient(C1).Letsrevisittheinitial
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-restrictedorsymmetricfrewall(Mode4)furthermandatesthatPxmustsignalC1usingasourceportof5060.
Somefrewallsfeatureconfgurableswitchescalledporttriggeringorestablishedudp,whichallowanadministrator
toopenmultiplepinholesonfrewallsasaworkaroundtotheabovesignalingasymmetry.However,suchoptionsare
notpractical,astheuserwhohasthephonebehindthefrewallmaynothaveadministrativecontroloverthefre-
wall.Therefore,toassuresuccessfultraversalacrossfrewallsthatsupportdynamicUDPadmission,itisrecommended
thatboththeinsideandoutsideentitiesusethesameporttosendandreceiveacertaintypeoftraffc.
Outbound Calls and 2-Way Media
AtypicaloutboundSIPcallinvolvesacallersignalingaproxywithanINVITE.TheproxythenrelaystheINVITEtothe
callee.TheSessionDescriptionProtocol(SDP)informationwithintheINVITEmessagetellsthecalleewheretosend
themedia.Whenthecallisaccepted,thecalleesendsa200OKmessagewithSDPinformationthattellsthecaller
wheretosendthemedia.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 6/20
Iftheoutboundcallerdoesnotsendthefrstmediastreamofthecall,thecallerwillonlybeabletohearmediafrom
thecalleeifhe/sheisbehindafrewallusingModes1through3.ThisisbecausearestrictedconeNATwillnotallow
ahost(thecallee)towhomthecallerhasnotrecentlysentapackettosendanyUDPinboundacrossthefrewall.
ForthecalltobesuccessfulwhenthecallerisbehindafrewallusingModes1through6,boththecallerandcallee
shouldsendmediaonthesameportastheydeclareintheSDPthattheywillbelisteningformedia.
Figure 3belowdisplaysanexampleofthisprocess.
Inthisfgure,thecallerlocatedat192.159.1.11:16384sendsoutanINVITEtothecalleewithSDPinformation
informingthecalleewheretosendmedia.Thecalleerespondsbysendinga200OKwithitsownSDPinformation,
afterwhichacallisestablishedbetweenthecallersportat16384andthecalleesportat8000.
Figure 3 : :OutboundCallsand2-WayMedia
Inthisexample,mediaisexchangedsymmetricallybetweenthecallerandcallee.Thissatisfesthepacketadmission
requirementsofthemorerestrictivefrewalls,aslongasthefrewallsthemselvesareconfguredtosupportRefexive
UDPAdmission.
If,atanytimeduringthecall,thecallerbehindthefrewallstopssendingmediaoutboundforasuffcientamountof
time,thereisnoguaranteethatthefrewallwillcontinuetoadmitincomingRealTimeProtocol(RTP)mediastreams.
ThisalsoappliestoRealTimeControlProtocol(RTCP)packets.Itislikelythatthefrewallwillnotadmitaninbound
RTCPpacketunlessanoutboundRTCPpackethasbeenemittedfromthecallertothecallee.Ifsuffcienttimehas
elapsedbeforethenextRTCPexchange,thereisapossibilitythatthepinholeforincomingRTCPwillbeclosed,and
theexternalcalleesendingtheRTCPpacketmaygetamessagefromthefrewallthattheInternetControlMessage
Protocol(ICMP)destinationisunreachable.
REGISTER Packet and Inbound Calls
MostSIPdeploymentsaresetupinsuchawaythatSIPphonessendaREGISTERpacketouttoaRegistrarProxy
uponstartup.Theregistersignal,whenauthenticatedandacceptedbytheRegistrarProxy,informsthecallerwhere
thecalleecanbereachedforfutureincomingrequests.Thiscoincidentallyopensupapinholeacrossthefrewallfor
incomingrequeststobedeliveredtotheclient.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 7/20
Asdiscussedearlier,thefrewallmayclosethepinholewhenaperiodofinactivityhaspassed.Commonmeasures
takentokeepthefrewallpinholeopenincludethefollowing:
ConfiguringtheSIPProxytosenddummykeep-alivepacketstotheclient.
ConfiguringtheSIPclientstosenddummykeep-alivepacketstotheSIPproxy.
ConfiguringtheSIPclientstore-registerwiththeSIPproxyapproximatelyevery30seconds.
Unfortunately,dummypacketsmaybeineffectiveintheNATcasestobediscussedlaterinthispaper,andincreasing
thefrequencyofre-registrationoftencarriesthepenaltyofoverwhelmingtheproxyregistrationdatabase.
Network and Port Translation Problems
NetworkAddressTranslation(NAT)addsfurthercomplicationstoSIP.ThisisbecauseSIPsignalingreliesonthe
IPaddressesandportnumberscontainedinthesignalingmessagepayload,andthispayloadcanbeimproperly
translatedbyNATenabledfrewalls.
Figure 4belowdisplaysanexampleofNATintroducedcomplications.Inthisexampletheinsideclient(C1)sendsa
SIPrequestpackettoanoutsideSIPproxy(Px)viaaNAT(Nx).
Notethatinthispaper,welimitourdiscussionofNATtothemostcomplex(andmostcommon)situation,wherethe
frewallexhibitsdynamicUDPadmissionandwherenostaticNATorPATforwardingisenabled.
Figure 4 : :NATComplications
IftheSIPproxy(Px)weretofollowtheembeddedViainrespondingtotheoriginalSIPmessage,thepacketwould
havebeensentto192.168.1.100,whichisunreachableontheInternet.
IftheSIPproxy(Px)weretosendaresponseaccordingtothesameUDPsourceaddress,itislikelythattheresponse
messagewillreachtheclient.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 8/20
However,hereliestheconfictwhenthepacketsentbytheclientisaREGISTERmessage.Figure 5below
displaystheconfict.
Figure 5 : :REGISTERMessage-Confict
AccordingtotheSIPspecifcation,theproxyshouldenterintoitsregistrartablethatclientC1isreachableat
192.168.1.100,port5060.Obviously,thisaddresswillnotbereachable.Forpracticalreasons,itshouldhaveentered
192.159.1.11:1024instead,aslongastheclientsignalssymmetrically(listensonport5060).Unfortunately,bydoing
this,theproxydeviatesfromtheSIPspecifcation.
NAT Port Contention and Port Rotation
MostNATfrewallsaredeployedinPortAddressProtocol(PAT)modebydefault,wheremanyinternalclientsshare
thesameglobal(external)IPaddressofthefrewall.
ConsiderthecasewheretwoSIPclients(C1andC2)arelocatedintheinternalnetworkandsendREGISTER
messagestothesameSIPproxy(Px)outside.ClientC1isat192.168.1.100andclientC2isat192.168.1.101.
Figure 6belowdisplaysaschematicofthisconfguration.
Figure 6 : :NATPortContention/Rotation
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 9/20
IftheNATdoesnottranslateportsbydefault,thefrstclient(C1)islikelytogetasourceportontheglobalIP
addressthatisidenticaltotheoriginalsourceportof5060.Ifthereisasecondhostontheinsideusingasourceport
of5060totalktotheSIPproxyatPx,thefrewallwillassignitarandomephemeralport(suchas192.159.11:1024).
However,thereisaphenomenonsimilartomusicalchairsthatislikelytohappen.Ifthefrsttranslationslotfor
192.168.1.100everexpiresandapacketissentfromC2ataddress192.168.1.101:5060,thenC2willlikelygetthe
translationslotof192.159.1.1:5060,andC1willgetanewtranslationslotof192.159.1.11:1025.
SowhathappenstoincomingcallstoC1?IftheSIPproxy(Px)remembersC1isat192.159.1.1:5060basedonthe
initialregistration,thenanincomingINVITEwillbesenttothewrongphoneandC2willlikelystartringing,oreven
rejectthecallbecausetheINVITEwouldcarryarequestURIof192.168.1.100:5060,andnot192.168.1.101:5060.
NAT and Media
LetsexaminetheproblemwithSDPandmedia.Considerthecasewhereacallerbehindafrewallcallsacallee
outsidethefrewall.Inthisscenario,thecallerislocatedbehindthefrewallat192.159.1.11:16384.Figure 7below
displaysaschematicofthisconfguration.
Figure 7 : :NATandMedia
SincethecalleereceivestheINVITEfromtheproxy,thecalleewillnothaveanyideawhatthefrewallglobalIP
addressofthecallerwouldbe,nottomentionthecorrectporttosendto.TheSDPinformationcontainedinside
theINVITEmessagesimplycannotbeused.
AcallerbehindaNATfrewallmaybeabletolearnwhatitstranslatedglobalIPaddressisaheadoftime.Inthis
outboundcase,theinitialINVITEcontainsthecorrectIPaddress.ConsiderthecasewheretheuserbehindaNAT
192.159.1.11alreadyknowsaheadoftimewhatthetranslatedaddresswillbe,andconfguresthephonetosend
SDPinformationtocontaintheglobalIP(Figure 8 onpage10).
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 10/20
Figure 8 : :NATandMedia-SecondExample
TheINVITErequeststhecalleetosendmediato192.159.1.11:16384,andthecallerstartslisteningonport16384for
incomingmedia.
NATfrewalls(withtheexceptionofFullConeNATs)disallowthecalleesmediapacketscominginbound.Thisisalso
anissuewithporttranslation.Forexample,whenthecallersendsmediaviaaNATtoacallee,theUDPstatecreated
intheNATmayhaveaportthatdiffersfromtheUDPportusedbythecaller.
TheSDPinformationembeddedintheoutboundINVITEhasaUDPportdeclared.Thisistheportfromwhichthe
callerwillsendmediaifitsendsandreceivesRTPmediasymmetrically.However,unlessthefrewallisguaranteed
nottoperformanyporttranslation,itisunlikelythatanincomingstreamfromthecalleetotheNATport(inour
example,portnumber16384)willbetranslatedandsentinboundtocalleeport16384.
IftheNATtypeismorerestrictivethanaFullCone,thequestionbecomeswhatthecallershouldsendacrossthe
frewalltocreatetheUDPstateentry(orpinhole)onthefrewall,suchthatincomingmediawillreachport16384.
IfthecallerknowsaheadoftimethatthecalleeisnotbehindaNAT,anditsSDPcanbetrusted,thenthecallercan
sendmediaassoonasa200OKisreceived(seeFigure 9onpage11).
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 11/20
Figure 9 : :CallerAwareCalleeNotBehindNAT
IftheexternalcalleeweretodisregardthecallersSDPdeclaredintheINVITE,butsendmediasymmetricallytothe
calleronceithasreceivedamediapacketfromthecaller,then2-waymediashouldbeestablished.However,wehave
notseenaSIPphoneinproductionthatiscapableofthis.
Furthermore,inthecasewherebothcallerandcalleearebehindtheirrespectivefrewalls,boththecallerandcallee
willbeinlimbo,waitingforeachothertobethefrsttosendmedia.
Common Attempts to Solve the Problems
ThefollowingsectiondescribesthecommonmeasuresusedtoachieveCPE-lessfar-endNATtraversalforSIP.With
theexceptionofTransmissionControlProtocol(TCP)signalingandUPnP,themethodsdescribedtakeadvantageof
signalingandmediasymmetryonalmostallnewerphones,andRefexiveUDPAdmissiononmostfrewallsintheir
actualdeployedconfguration.
Using TCP
UsingTCPforsignalingandconfguringtheproxy(wherepossible)toignoremismatchingViaandContactheaders
causedbyNATstoacertainextentcanwork.However,toensurethatinboundcallscanreachclientsbehindfrewalls,
persistentTCPconnectionsmustbemadewiththeproxy,whichdramaticallyreducesscalabilityandcreatesa
signifcantamountofnetworkoverhead.Furthermore,mostNATfrewallshaveTCPidletimeouts,mandatingthe
useofkeep-alivepacketsacrosstheTCPconnection.NotethatTCPonlyaddressessignaling,becauseRTPandRTCP
arestilltransmittedinUDP.
UPnP
UniversalPlugandPlay(UPnP)clientstrytosignaltheNATfrewalltopre-allocatenumerousUDPportstoallowboth
incomingsignalandmedia.Inpractice,thereisoftenconfusionintheallocationoftheseportswhenmorethanone
clienttriestoopenthesamerangeofUDPports.Sincealargepercentageoffrewallsarenotconfguredtohave
UPnPenabled,onecannotrelyonUPnPtowork,especiallywhenusersmaynotknowwhetherthefrewallthey
arebehindisactuallyUPnPcompatible.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 12/20
STUN
SomeIPphonevendorsareimplementingSimpleTraversalofUDPthroughNAT(STUN),whichisinIETFDraftstage
(RFC3489).STUNisaprotocolthatletsthephonequeryanexternalservertovalidateitsexternalIPaddress/port.
Unfortunately,STUNdoesnotworkinthecommoncorporatefrewallexampleofasymmetricNAT.
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
maybeduetothefactthatthefrewallchoosesadifferentbindingforadifferenthost(STUNservervs.callee),oritis
adifferentbindingduetoadifferentdestinationport(3478vs.8000inthisexample).
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 13/20
Figure 12below,displaysaschematicofthisexample.Whenthecalleetriestosendmediatoport1024onthe
frewallbasedontheSDPinformation,itgetsblocked.
Figure 12 : :BlockedMedia
Furthermore,thereisnotellingwhethertheexternalhostwillsendmediasymmetrically.Manymediaserversfor
voicemail,IVR,andconferencedonotsendandreceivemediaonthesameport.Thiscreatesamediaasymmetry
forwhichevenPort-restrictedConefrewallswillnotwork.
NewerphonesoftenexecuteaSTUNtesttonotifytheuserwhattypeofNATfrewallthephoneisbehind.
However,sinceNATbindingscanchangeorexpirewithoutwarning,aSTUN-enabledphonebehindaNATfrewall
shouldregularlyreconfrmitsglobaladdressandportswiththeSTUNservers,andpreferablyrightbeforeitsendsa
requestsignal.Unfortunately,thiscarriesthepenaltyofaddingloadtothenetwork.
Inrarecases,aRestrictedConeNATmayexhibitthebehaviorofaSymmetricNAT.Thesesymptomsareobservable
whenaphonefrequentlyre-registersfromdifferentglobalsourceports.Thismaybeduetotheinadvertentclearing
ofthetranslationtableforconfgurationchangesthatmandatetherestartingofthefrewall,crashes,orsimplya
failuretofollowthetranslationtimeoutsbasedoninactivity.
Ingeneral,STUNcanworkwell,butonlywhenthefollowingconfgurationexists:
TheSTUNclientisbehindaNATthatislessrestrictivethanaPort-restrictedCone,and
Thesignalingproxysignalssymmetrically,and
Theendpoint,iflocatedontheexternalnetwork,emits/receivesRTPsymmetrically, ortheotherendpointisa
STUNclient.
TURN
AsignifcantsupplementtoSTUNthatutilizesanexternally-hostedMediaProxytodealwithsymmetricNATsis
TraversalUsingRelayNAT(TURN).ThegoalofTURNistoenablecallstopassthroughsymmetricNATs.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 14/20
EndpointscouldbeequippedwiththeintelligencetonegotiatewiththeTURNservertoallocateandsendmedia
toaglobally-routablemediarelay.InsteadofsendingmediabasedonSDPinformation,itrelaysmediaforeachcall
symmetrically,usingthesamesourceportonwhichitlistensforincomingmedia.
Amajorcriticismofthisapproachistheamountofbandwidthwastageandlatencyinducedbyroutingallmediato
acentralrendezvouslocation,andsubsequently,totheotherparty.Callsbetweentwoneighboringendpointsoften
fndtheirmediaroutedoutthefrewallandbackunnecessarily.
Signaling/Media Proxy Combination
TURNrequiresintelligencebuiltintotheendpointstosignalaTURNserver.Analternativeapproachistohavean
externalMediaProxythatoperatesinconjunctionwithaRegistrar/SignalingProxythatmodifesSDPascallsignals
passthrough.
Thisapproachdoesnotrequireendpointstohavetheintelligencetoperformanyglobaladdressdiscoveryorpre-call
signalingwithaTURNserver.AslongastheendpointssendandreceivemediasymmetricallyandtheNATsinvolved
supportrefexiveUDPadmission,thereshouldbenotroublegettingcallsthrough.
However,thisapproachsuffersthesamedrawbackastheSTUN/TURNcombinationintermsofbandwidtheffciency
andscalability,andtheSIPproxyoftenperformsunnecessaryre-routingofmediabetweenclientsthatarenotbehind
frewallsorNATs.
ICE
InteractiveConnectivityEstablishment(ICE)isamethodthattriestobuildintelligenceintoendpointssothatthey
canperformroutediscovery,pathoptimization,andevenverifymediafowbeforeacallisdeemedtobeestablished.
PriortosendinganINVITE,thecallerperformsasequenceofstepstocharacterizethefrewallthatitisbehind:
Obtainsaddressesofallusableinterfaces(local,VPN)
CheckstheresultsfromSTUN
Ifneeded,negotiatesaportwiththeTURNserver
Afterwards,thecallersendsalistofavailableIPaddresses/portsintheINVITEtotheproxy.
AssoonasthecalleegetstheINVITE,itfollowsasimilarsetofstepsasdidthecaller.Next,itattemptstosendSTUN
queriestothecallertoseeifitispossibletodirectlysendmediatoanyoftheIPaddressesitpresentedintheINVITE.
Finally,thecalleepickstheaddressofhighestpreferenceintheINVITEtowhichthecalleecanconfdentlysendmedia.
ThisapproachiscompatiblewithmostknownfrewallsthatsupportUDP.Inadditiontoworkingwithalltypesof
NATsthatsupportrefexiveUDPadmission,italsoworkswiththeveryrestrictivefrewallsthataredeliberately
confguredtoonlyallowinternalhoststoconverseusingUDPwithoneortwohostsontheoutside.However,for
ICEtoworkproperly,bothcallerandcalleemustsupportICE,andthereshouldreadilybeaSTUNandTURNserver
available.Forthisreason,itshouldbedeployedonlyinahomogeneous,controlledenvironment.Furthermore,it
islikelythatthecallsetupwillbedelayedbecauseofthestepsinvolvedinmediapathdiscoverybyboththecaller
andcallee.
Finally,withtheendpointsadvertisingtheirowninternalIPaddresses,ICEmaynotmeetthetopologyhiding
requirementsofsecurity-focusedenvironments.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 15/20
Using an External B2BUA/MP
Theapproachesdiscussedthusfarinthispapercanonlysolveselectedproblemssomeofthetime.Furthermore,
theyoftenrequireadditionalintelligenceontheendpoints,whichmaynotalwaysbeavailable.
Fortunately,anapproachhasbeendiscoveredthatworksinvirtuallyallsituationsthatdoesnotrequireanyadditional
customer-premiseequipment,software,orfrewallconfguration.TheresultofapplyingthisapproachisthatVoIP
signalingandmediastreamscanbemadetotraverseanarbitrarynumberof(possiblynested)NAT,PAT,andfrewall
devices,usinganystandards-compliantendpoint.Thisapproachhastheaddedbeneftthatinalmostallcases,no
additionalmediaworkloadorlatencyisintroduced,sincethemediastilltraveldirectlyfromcallertocallee,and
viceversa.
ThisapproachinvolvestheuseofaSessionBorderController(SBC)thatcontainsaSIPBack-to-BackUserAgentwith
anembeddedMediaProxy(B2BUA/MP).TheB2BUA/MPislocatedintheserviceprovidersnetwork,fromwhereit
canseeandreachtheglobalIPaddressesandportnumbersofallcallparticipants.Theendpointsinacallareset
uptoeitherregisterthroughtheB2BUA/MP,ortouseitastheiroutboundproxy(asperIETFRFC3261).Thejob
oftheB2BUA/MPistoacceptcallsignalingandmediastreamsfromendpointslocatedbehindNATdevices,andto
sanitizethosestreamssothattheycanbesentfurtheroutontotheglobalInternet.Itisnotnecessaryforboth
endpointstobebehindthesameB2BUA/MP.Indeed,oneendpointcanbebehindoneandtheotherendpoint
behindanother,oroneendpointcanbebehindonewhiletheotherusessomeothermeanstodealwithitsownNAT
problems.Oneofthemajoradvantagesofthisapproachisthatitdoesnotrequireanyspecialdeviceorconfguration
tobepresentatbothendsofacall.
Thefollowingexample(Figure 13below)showshowaB2BUA,confguredastheoutboundproxyoftheclient,can
functionasafar-endNATtraversaldevice.
Figure 13 : :B2BUAasaNATTraversalDevice
TheregistrarproxynowhastheuserlocationinformationofC1attheB2BUA.Whenproperlyimplemented,the
B2BUAdoesnothavetokeepastaticallyprovisioneddatabaseofusers,nordoestheproxyneedtobestatically
confguredwithuserlocationspointingattheB2BUA.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 16/20
ToensurethatuserC1isalwaysreachableincaseofinboundcalls,theB2BUAusesvarioustypesofSIPsignalsto
encouragetheclientC1toregularlysendSIPtraffctotheB2BUA.ThisfowofSIPsignalsatregularintervalshelps
maintainthepinholeatthefrewall.IncaseofanunexpectedpinholeclosureorchangeinUDPstatebrought
aboutbyfrewallanomalies,thisheartbeattraffcservestoinformtheB2BUAoftheclientsnewgloballocation.
Topreventtheproxyfrombeingoverwhelmedbythisheartbeattraffc,thesignalsarenotpassedtotheproxy
unnecessarily.AsanadditionalmeasuretodealwithclientsthatdonotobeytherequestbytheB2BUAtosend
outboundmessages,theB2BUAinitiatesSIPmessagestoclientsperiodicallytoverifytheirrespectivelocations.
Whenproperlyimplemented,allthesignalsmentionedaboveshouldbegenericSIPsignalsthatshouldnotcause
anyproblemstoanySIPendpoints.
TheB2BUAalwaysusesthesameporttocommunicatewiththeclient,whichmakesitcompatiblewithsymmetric
NATs.UnlikeUPnP,wheretheclientopensmultipleportsacrossthefrewallformultipleexternalhosts,thereisno
requirementfortheclienttoopenadditionalpinholesacrossthefrewall.
Whenacallisinitiated,theB2BUAmodifesthesignals,informingboththecallerandcalleetosendtheirmedia
topre-allocatedportsonaMediaProxy,oftenconfguredtorunonthesamemachineastheB2BUA.Atregular
intervals,theB2BUAusesstandards-compliantSIPsignalstoverifythatbothcallerandcalleearestillonthecall.
Inthemostchallengingscenario,bothcallerandcalleeareeachbehindtheirownsymmetricNATs.SincetheMedia
Proxyisengagedatthestartofthecall,bothpartiesreceivemediafromeachother,providedthateachsidehassent
atleastoneRTPpacket.Ifnofurtheractionistakentooptimizethecall,thebehavioroftheB2BUAissimilartothe
Signaling/MediaProxycombinationmentionedearlierinthisdocument,havingthesamedrawbacksofmedialatency
andbandwidthwastage.
UnlessonepartyonthecallisbehindasymmetricNATwithfrequentporttranslationchanges,itispossibleto
re-directthemediaduringthemiddleofacall,wherethecallersendsthemediatothecorrectportonthefrewall
thathidesthecallee,andviceversa.ItisalsopossiblefortheB2BUAtousestandards-compliantSIPsignalsto
characterizethetypeofNATfrewallinfrontofeachpartyonthecall.Thisisdonebyinspectingthecharacteristics
ofthemediafowaftereachofthoseNAT-characterizedsignalshasbeensent.ThistechniqueiscalledMediaPath
Optimization(MPO).Figure 14onpage17displaysaschematicoftheprocessfortheB2BUA/MP.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 17/20
Figure 14 : :B2BUA/MPProcess
Figure 14displaysthefollowingstepsintheB2BUA/MPprocess:
1. AssumingcalleeC2hasregistered,callerC1sendsanINVITE.
2. TheSIPproxyserver(Px)locatesC2attheB2BUA.
3. TheB2BUAsendsanINVITEtoC2sfirewall.Notethatthesignalingprocessthatestablishesthecallhas
beenomittedhere.
4. Theinitialmediaflowhasboththecallerandcalleesendingmediatothemediaproxy.
5. TheB2BUAnowstartsNATcharacterizationofthefirewallsonbothsides.
6. TheB2BUAsendssignalstobothendpoints,tellingthemtosendthemediatospecificportsontheother
partysfirewall.
7.TheB2BUAsuccessfullyremovesitselffromthemediapath,butitstillmaintainscontrolofcallsignaling.
Thekeydifferentiatorofaport-translatingsymmetricNATfromotherNATtypesisthatadifferentglobal-to-local
port-mappingisusedifthesameinternalhostsendsapacketwiththesamesourceaddressandport,buttoa
differentdestinationhostordestinationport.ByobservingthechangesinmediabehaviorwitheverySIPsignal
senttoeachpartyonthecall,theMediaProxycandeterminewhetheraclientisbehindaport-translatingsymmetric
NAT.IfeitherpartyisbehindsuchaNAT,theMediaProxymustcontinuetoproxythemediaforthecall.Fortunately,
thepercentageofsymmetricNATsdeployedremainsrelativelysmall,especiallyinSmallOffce/HomeOffce(SOHO)
environments.AsidefromNATcharacterization,SIPsignalsgeneratedbytheB2BUAmediapathoptimization
sequencealsohelptodeterminewhetherbothclientsonthecallaretolerantofmediaredirection.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 18/20
SinceNATcharacterizationisperformedafterthecallhasbeensetupandmediaisbeingreceivedbybothparties,
extremecaremustbetakentoavoidlossofmediaduringtheprocedure.TheMediaProxyshouldnotdisengageitself
untilacertaintimehaselapsedaftermediapathoptimizationhascompleted,andbothclientsaresendingmediato
theotherpartysrespectiveglobaladdressandport.IftheMediaProxyeverdetectsanundesirablebehavioronthe
partoftheclientorfrewall,SIPsignalsshouldbegeneratedbytheB2BUAtoinformtheclientstorevertbacktothe
originalmediapath.
Additionally,thereareotherissuestobeconsideredwhenmediapathoptimizationisexecuted.TheB2BUAcannot
simplyattempttogloballyoptimizeallcalls.Someuseragentsdonotreactproperlytomediaredirectingandwillnot
sendmediatotheredirecteddestination.
ThereisalsotheissueofwhethertohavethepartieswhoareapparentlybehindthesameNAPTaddresssend
mediatotherespectiveportsontheNATglobaladdress,orwhethertheyshouldsendmedialocallytoeachother.
AsignifcantpercentageofNATswillnotrelayhairpinmediausingtheirglobalIPaddresses.Thatis,twohostson
theinternalsideoftheNATmaynottalktoeachotherbyusingtheglobalIPaddressoftheNAT.Ontheotherhand,
redirectingtheRTPfowtoeachpartyslocaladdressmaynotworkwellinthecasewherethereisonepartybehind
asecondlevelofcascadedNATcallingapartylocatedinadifferentcascadinglevel.Suchcasesmandatedisabling
mediapathoptimizationforcertainglobaladdresses,orusingslavemediarendezvouspointsstrategicallylocated
tominimizebandwidthwastage.
InadditiontoresolvingtheNATtraversalissues,anSBCwithaB2BUAcanprovideotherbeneftsthatareoften
criticaltotheVoIPnetwork,suchas:
Topologyhiding
ProtectingservicefromDOSattacks
EnforcingQoSpolicies
Ensuringend-to-endinteroperability
Billing
Per-sessiontroubleshooting
Lawfulintercept
Summary
MostprovidersofIPtelephonyservicesbelievethattheexperienceofausershouldmirrortheeaseofuseand
ubiquitousavailabilityofthePublicSwitchedTelephoneNetwork(PSTN).Indeed,inmanycases,theeconomicsof
providingservicerequirethatthingssimplyworksothatcustomersupportexpensesarekepttoaminimum.Given
thecomplexityoftodaysNATandfrewallprotectednetworksbothinresidentialandenterpriseenvironments
thiskindofubiquitousreliabilityforVoIPcanonlybesuccessfullyprovidedwithsomehelpfromaNATtraversal
system.Again,drivenmostlybyeconomics,suchasystemmustnotrequireanyspecialhardwareorsoftwareonthe
userspremises,andmustnotrequireeithertheserviceproviderortheusertohaveanyspecialknowledgeofthe
topologyofthenetwork(orhowitsNATandfrewallcomponentsaretobeconfgured).ThegoalofaNATtraversal
systemforreal-worlddeploymentmustthereforebetosolveusersNATandfrewallproblemsremotely,andfrom
theserviceprovidersnetwork.
Practical Far-End NAT Traversal for VoIP
Cop,||| 2007 0|ec| Newo||s 19/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.DitechNetworksVoIPproductscombineVQAtechnologywithpacketvoiceprocessingandsecurity
capabilitiestoenablecarrierstodeployend-to-endVoIPservicesacrossnetworksecurityboundarieswithout
requiringnetworkre-architecting.Ditech(Nasdaq:DITC)isheadquarteredinMountainView,California,USA.
Practical Far-End NAT Traversal for VoIP
20/20
Corporate Headquarters
US Sales West
DitechNetworks
825EastMiddlefieldRd.
MountainView,CA94043
USA
1-800-234-0884(TollFree)
1-650-623-1300(Direct)
1-650-564-9599(Fax)
NA-Sales@ditechnetworks.com
US Sales Office East and Central
DitechNetworks
8360GreensboroDr.
McLean,VA22102
USA
1-800-234-0884(TollFree)
1-650-623-1300(Direct)
1-650-564-9599(Fax)
NA-Sales@ditechnetworks.com
Canada Sales Office
DitechNetworks
2275LakeshoreBlvdWest,Suite500
Toronto,ONM8V3Y3
Canada
1-416-255-7776(Phone)
NA-Sales@ditechnetworks.com
Mexico Sales Office
DitechNetworks
TorcuatoTasso245-6o.Piso
Col.Polanco
Mxico,D.F.C.P.11570
Mxico
+52(55)5254-5422(Main)
+52(55)5350-8679(Sales)
Mexico-Sales@ditechnetworks.com
Brazil Sales Office
DitechNetworks
AlamedaAraguaia,933
Alphaville
Barueri,SP06455-000
Brazil
+55(11)4208-6266(Main)
+55(21)3521-5543(Sales)
Brazil-Sales@ditechnetworks.com
South-America-Sales@ditechnetworks.com
China Sales Office
DitechNetworks
Unit3010,No.500
XiangyangSouthRoad
XuhuiDistrict
Shanghai200031
PRC
+86(21)54560305(Phone)
China-Sales@ditechnetworks.com
South-East Asia Sales Office
DitechNetworks
LippoPlaza3rdFloor
Jl.Jend.SudirmanKav.25
Jakarta12920
Indonesia
+62(21)52913780(Phone)
+62(21)5221977(Fax)
SE-Asia-Sales@ditechnetworks.com
South Asia Sales Office
DitechNetworks
No.8/11,SarvapriyaVihar
NewDelhi110016
India
+919810372555(Phone)
South-Asia-Sales@ditechnetworks.com
Middle East/Africa Sales Office
DitechNetworks
21El-FawakehSt.,3rdFloor
Dokki,Giza12311
Egypt
+202336-5100(Phone)
+202761-8964(Fax)
MEA-Sales@ditechnetworks.com
Spain Sales Office
DitechNetworks
TorresQuevedo,1(P.T.M.)
28760TresCantosMadrid
Spain
+34(91)8037444(Main)
+34(91)8292690(Sales)
Spain-Sales@ditechnetworks.com
Europe-Sales@ditechnetworks.com
Cop,||| 2007 0|ec| Newo||s. /|| |||s |ese|.ed. vC/ |s a |adera|| o 0|ec| Newo||s. /|| o|e| b|auds a|e |e p|ope|, o |e|| |espec|.e owue|s.
'pec|ca|ous ra, c|aue w||ou uo|ce. !||s docureu was |as |e.|sed 02/07.