Upload
sandra4211
View
3.478
Download
2
Embed Size (px)
Citation preview
| W H I T E P A P E R |
Practical Far-End NAT Traversal for VoIP
March 2006
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
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.
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)
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.
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.
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.
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
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).
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).
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.