WP Far End NAT Traversal

8/3/2019 WP Far End NAT Traversal

1/20

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

Practical Far-End

NAT Traversal for VoIP

March 2006


2/20

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


3/20


Copyright 2007 Ditech Networks /20

IntroductionThegoaloar-endNATtraversalistoallowinboundandoutboundVoIPcallstosucceedinthehighestpossible

numberocases,evenwhenoneorbothcallpartiesonthecallarebehindoneormoreaddress-translation-enabled

rewalls.Norequirementsonthesubscriber-premiseshardware,sotware,orrewallshouldbepermittedthe

subscribersexperienceshouldbetosimplypluginaproperlyconguredVoIPphoneandstartmakingcalls.This

paperdiscussestheissuesthatmustbeconsideredandthesolutionsrequiredtoachievethisgoal.

Webeginbyexaminingtheeectsorewallsintheirroleaspacketadmissioncontrollingpoints,andthenlookinto

themorecomplicatedissuesarisingromNetworkAddressTranslation(NAT)andPortAddressTranslation(PAT).

Packet Admission Policy Problems

BeorediscussingtheissuesoNATandPAT,administratorsmustunderstandthatnetworkrewallscreatemanyo

VoIPsproblemswiththeirpacketadmissionpolicies.ThisisbecauserewallsarethegatekeeperotheUDPprotocol

whichisrequiredbyVoIP.Bydeault,rewallsaretypicallyconguredtobehaveinoneormoreotheollowing

modes,listedinorderorestrictiveness.

Packet Admission Policy Modes

1.AllowallUserDatagramProtocol(UDP)datagramstocomeinthroughtheirewall(Open).

2.AllowonlycertainhoststosendUDPinbound.

3.AllowcertainhoststosendUDPinboundonlyromcertainports,andonlytocertaininsidehostsoncertainports.

4.AllowallexternalhoststosendinboundUDPtoanyinsidehost,providedthatthesametypeotraichasrecently

beenemittedoutboundromanyinsidehost/port.ThisiscalledaFullConeNAT.

5.AllowanexternalhosttosendinboundUDPromanyporttoaninsidehost,providedthatthesametype

otraichasrecentlybeenemittedoutboundromanyinsidehost/porttothatexternalhost.Thisiscalleda

RestrictedConeNAT.

6.AllowanexternalhostandonlythatspeciicexternalhosttosendinboundUDPusingthesameportpairtoan

insidehost.ThisiscalledaPort-restrictedConeorSymmetricNAT.Notethatthereisalsoaurtherdierence

betweenaPort-restrictedConeandSymmetricNATwhichrelatestotheuseodierentglobal-porttolocal

host-portbindingsortraicexchangesbetweenasingleinternalhosttodierentexternalhosts.

7.AllowanexternalhosttosendinboundUDPtoaninsidehost,providedthatthesametypeotraic(host/port)

hasrecentlybeenemittedoutboundtoaportattheexternalhostthatislowerthan1024.Thisisamore

restrictivevariantoPort-restrictedConeorSymmetricNAT.

8.BehaveasaproxyserverthatonlyallowsinboundUDPtraicromspecialconigurationsontheclients.

9.DenyallinboundUDPtraicandresponses(Closed).

TheconceptoCPE-lessNAT/FirewalltraversalrestsonthepremisethatUDPresponsesromatleastoneserveron

theoutsidenetworkmustbeallowedtopassthrough.

DierentvendorsusedierentterminologytodescribeModes4through7intheirrewallcongurations.Themost

commonnamesincludeStateulInspection,AdaptiveSecurityAlgorithm,StateulUDPConnectionCache,and

RefexiveUDPAdmission.


4/20



WewillusethetermRefexive UDP Admissiontodescriberewallsthatallowanexternalhosttorespondsymmetri-

callywithinagivenperiodotime.Wewillalsocallthistemporaryadmissionoresponsesapinhole.Mostrewalls

supportRefexiveUDPAdmissionbydeault,butrewallvendorsusuallydonotdisclosewhichtypeamongthe

abovemodesthatthedeaultbehaviororUDPadmissionallsinto.

Pinhole Timeout Thresholds

Additionally,mostrewallvendorsdonotdisclosethelengthotheinactivityperiodaterwhichadynamic

pinholeisclosed.Inourobservations,multipleinboundpacketsareusuallyacceptedor30secondsto10minutes

ateranoutboundpackethasbeensent.

However,somerewallsmayarbitrarilyclosethepinholes,whichhaltstheexternalentitysabilitytosend

inboundcalls.

Signaling Asymmetry

SignalingasymmetryoccurswhenaclientatanIPandportaddressdeclaresadierentIPaddressorportin

theViaand/orContactheadersthataredierentromtheIPaddressorportactuallyusedtoemitthatSIPsignal.

Forexample,considerthescenariowherethereisanexternalSessionInitiationProtocol(SIP)proxyserver(Px)

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

rewallsendsaUDPsignalromtherandomlyassignedephemeralport12345tothePxportlocatedat5060.

Theclienthastheoptiontochooseaporttolistentoorresponsesanduturerequests.I,intheSIPsignaling

packet,theclientdeclaresaVia:inormationandContact:inormationo192.159.1.11:12345(thesameasitsactual

addressandport),therewillbenoproblemsorrewallsconguredtobehaveaccordingtoModes1through4as

previouslymentioned.However,thisgeneralrulemaybesubjecttotheproblemsdescribedbelow.

Client-Side Signaling Asymmetry

Client-sidesignalingasymmetryoccurswhenaclientdeclaresadierentcontactportintheVia.

Inthisscenario,iaclientdeclaresaVia:portthatisdierentromthesourceportusedtosendouttheinitial

outboundsignal(mostlikelyaREGISTER),thenrewallsthatareconguredtobemorerestrictivethanMode3

willnotallowsuchresponsepacketstoreachtheclientatthedeclaredport.

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

withadeclaredVia:192.159.1.11:5060,thentheexpectationisortheservertosendtheresponsetoaportother

thantheinitialephemeralport.Figure 1displaysaschematicoasuccessulclient-sidesignalingasymmetry.

Figure 1: : Client-SideSignalingAsymmetry(Successul)


5/20



Itheserverrespondsbacktoport5060,itwillnotpassthroughtherewall.Figure 2displaysaschematicoan

unsuccessulclient-sidesignalingasymmetry.

Figure 2 : :Client-SideSignalingAsymmetry(Unsuccessul)

Server-Side Signaling Asymmetry

ThereareseveralwaysaSIPproxyserver(Px)cansendresponsesbacktotheclient(C1).Letsrevisittheinitial

outboundsignalromtheaboveexample.TheclientlocatedatIPaddress192.159.1.11andport12345now

declaresintheVia:192.159.1.11:12345totheSIPproxylocatedat204.3.1.11:5060.

Theexternalservermayrespondintheollowingways:

RespondusingadierentIPaddress:allowedonlybyMode1.

192.159.1.11:12345


6/20



Itheoutboundcallerdoesnotsendtherstmediastreamothecall,thecallerwillonlybeabletohearmediarom

thecalleeihe/sheisbehindarewallusingModes1through3.ThisisbecausearestrictedconeNATwillnotallow

ahost(thecallee)towhomthecallerhasnotrecentlysentapackettosendanyUDPinboundacrosstherewall.

ForthecalltobesuccessulwhenthecallerisbehindarewallusingModes1through6,boththecallerandcallee

shouldsendmediaonthesameportastheydeclareintheSDPthattheywillbelisteningormedia.

Figure 3belowdisplaysanexampleothisprocess.

Inthisgure,thecallerlocatedat192.159.1.11:16384sendsoutanINVITEtothecalleewithSDPinormation

inormingthecalleewheretosendmedia.Thecalleerespondsbysendinga200OKwithitsownSDPinormation,

aterwhichacallisestablishedbetweenthecallersportat16384andthecalleesportat8000.

Figure 3 : :OutboundCallsand2-WayMedia

Inthisexample,mediaisexchangedsymmetricallybetweenthecallerandcallee.Thissatisesthepacketadmission

requirementsothemorerestrictiverewalls,aslongastherewallsthemselvesareconguredtosupportRefexive

UDPAdmission.

I,atanytimeduringthecall,thecallerbehindtherewallstopssendingmediaoutboundorasucientamounto

time,thereisnoguaranteethattherewallwillcontinuetoadmitincomingRealTimeProtocol(RTP)mediastreams.

ThisalsoappliestoRealTimeControlProtocol(RTCP)packets.Itislikelythattherewallwillnotadmitaninbound

RTCPpacketunlessanoutboundRTCPpackethasbeenemittedromthecallertothecallee.Isucienttimehas

elapsedbeorethenextRTCPexchange,thereisapossibilitythatthepinholeorincomingRTCPwillbeclosed,and

theexternalcalleesendingtheRTCPpacketmaygetamessageromtherewallthattheInternetControlMessage

Protocol(ICMP)destinationisunreachable.

REGISTER Packet and Inbound Calls

MostSIPdeploymentsaresetupinsuchawaythatSIPphonessendaREGISTERpacketouttoaRegistrarProxy

uponstartup.Theregistersignal,whenauthenticatedandacceptedbytheRegistrarProxy,inormsthecallerwhere

thecalleecanbereachedorutureincomingrequests.Thiscoincidentallyopensupapinholeacrosstherewallor

incomingrequeststobedeliveredtotheclient.


7/20



Asdiscussedearlier,therewallmayclosethepinholewhenaperiodoinactivityhaspassed.Commonmeasures

takentokeeptherewallpinholeopenincludetheollowing:

ConiguringtheSIPProxytosenddummykeep-alivepacketstotheclient.

ConiguringtheSIPclientstosenddummykeep-alivepacketstotheSIPproxy.

ConiguringtheSIPclientstore-registerwiththeSIPproxyapproximatelyevery30seconds.

Unortunately,dummypacketsmaybeineectiveintheNATcasestobediscussedlaterinthispaper,andincreasing

therequencyore-registrationotencarriesthepenaltyooverwhelmingtheproxyregistrationdatabase.

Network and Port Translation Problems

NetworkAddressTranslation(NAT)addsurthercomplicationstoSIP.ThisisbecauseSIPsignalingreliesontheIPaddressesandportnumberscontainedinthesignalingmessagepayload,andthispayloadcanbeimproperly

translatedbyNATenabledrewalls.

Figure 4belowdisplaysanexampleoNATintroducedcomplications.Inthisexampletheinsideclient(C1)sendsa

SIPrequestpackettoanoutsideSIPproxy(Px)viaaNAT(Nx).

Notethatinthispaper,welimitourdiscussionoNATtothemostcomplex(andmostcommon)situation,wherethe

rewallexhibitsdynamicUDPadmissionandwherenostaticNATorPATorwardingisenabled.

Figure 4 : :NATComplications

ItheSIPproxy(Px)weretoollowtheembeddedViainrespondingtotheoriginalSIPmessage,thepacketwould

havebeensentto192.168.1.100,whichisunreachableontheInternet.

ItheSIPproxy(Px)weretosendaresponseaccordingtothesameUDPsourceaddress,itislikelythattheresponse

messagewillreachtheclient.


8/20



However,hereliestheconfictwhenthepacketsentbytheclientisaREGISTERmessage.Figure 5below

displaystheconfict.

Figure 5 : :REGISTERMessage-Confict

AccordingtotheSIPspecication,theproxyshouldenterintoitsregistrartablethatclientC1isreachableat

192.168.1.100,port5060.Obviously,thisaddresswillnotbereachable.Forpracticalreasons,itshouldhaveentered

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

this,theproxydeviatesromtheSIPspecication.

NAT Port Contention and Port Rotation

MostNATrewallsaredeployedinPortAddressProtocol(PAT)modebydeault,wheremanyinternalclientsshare

thesameglobal(external)IPaddressotherewall.

ConsiderthecasewheretwoSIPclients(C1andC2)arelocatedintheinternalnetworkandsendREGISTER

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

Figure 6belowdisplaysaschematicothisconguration.

Figure 6 : :NATPortContention/Rotation


9/20



ItheNATdoesnottranslateportsbydeault,therstclient(C1)islikelytogetasourceportontheglobalIP

addressthatisidenticaltotheoriginalsourceporto5060.Ithereisasecondhostontheinsideusingasourceport

o5060totalktotheSIPproxyatPx,therewallwillassignitarandomephemeralport(suchas192.159.11:1024).

However,thereisaphenomenonsimilartomusicalchairsthatislikelytohappen.Ithersttranslationslotor

192.168.1.100everexpiresandapacketissentromC2ataddress192.168.1.101:5060,thenC2willlikelygetthe

translationsloto192.159.1.1:5060,andC1willgetanewtranslationsloto192.159.1.11:1025.

SowhathappenstoincomingcallstoC1?ItheSIPproxy(Px)remembersC1isat192.159.1.1:5060basedonthe

initialregistration,thenanincomingINVITEwillbesenttothewrongphoneandC2willlikelystartringing,oreven

rejectthecallbecausetheINVITEwouldcarryarequestURIo192.168.1.100:5060,andnot192.168.1.101:5060.

NAT and Media

LetsexaminetheproblemwithSDPandmedia.Considerthecasewhereacallerbehindarewallcallsacallee

outsidetherewall.Inthisscenario,thecallerislocatedbehindtherewallat192.159.1.11:16384.Figure 7below

displaysaschematicothisconguration.

Figure 7 : :NATandMedia

SincethecalleereceivestheINVITEromtheproxy,thecalleewillnothaveanyideawhattherewallglobalIP

addressothecallerwouldbe,nottomentionthecorrectporttosendto.TheSDPinormationcontainedinside

theINVITEmessagesimplycannotbeused.

AcallerbehindaNATrewallmaybeabletolearnwhatitstranslatedglobalIPaddressisaheadotime.Inthis

outboundcase,theinitialINVITEcontainsthecorrectIPaddress.ConsiderthecasewheretheuserbehindaNAT

192.159.1.11alreadyknowsaheadotimewhatthetranslatedaddresswillbe,andconguresthephonetosend

SDPinormationtocontaintheglobalIP(Figure 8onpage10).


10/20



Figure 8 : :NATandMedia-SecondExample

TheINVITErequeststhecalleetosendmediato192.159.1.11:16384,andthecallerstartslisteningonport16384or

incomingmedia.

NATrewalls(withtheexceptionoFullConeNATs)disallowthecalleesmediapacketscominginbound.Thisisalso

anissuewithporttranslation.Forexample,whenthecallersendsmediaviaaNATtoacallee,theUDPstatecreated

intheNATmayhaveaportthatdiersromtheUDPportusedbythecaller.

TheSDPinormationembeddedintheoutboundINVITEhasaUDPportdeclared.Thisistheportromwhichthe

callerwillsendmediaiitsendsandreceivesRTPmediasymmetrically.However,unlesstherewallisguaranteed

nottoperormanyporttranslation,itisunlikelythatanincomingstreamromthecalleetotheNATport(inour

example,portnumber16384)willbetranslatedandsentinboundtocalleeport16384.

ItheNATtypeismorerestrictivethanaFullCone,thequestionbecomeswhatthecallershouldsendacrossthe

rewalltocreatetheUDPstateentry(orpinhole)ontherewall,suchthatincomingmediawillreachport16384.

IthecallerknowsaheadotimethatthecalleeisnotbehindaNAT,anditsSDPcanbetrusted,thenthecallercan

sendmediaassoonasa200OKisreceived(seeFigure 9onpage11).


11/20



Figure 9 : :CallerAwareCalleeNotBehindNAT

ItheexternalcalleeweretodisregardthecallersSDPdeclaredintheINVITE,butsendmediasymmetricallytothe

calleronceithasreceivedamediapacketromthecaller,then2-waymediashouldbeestablished.However,wehave

notseenaSIPphoneinproductionthatiscapableothis.

Furthermore,inthecasewherebothcallerandcalleearebehindtheirrespectiverewalls,boththecallerandcallee

willbeinlimbo,waitingoreachothertobethersttosendmedia.

Common Attempts to Solve the Problems

TheollowingsectiondescribesthecommonmeasuresusedtoachieveCPE-lessar-endNATtraversalorSIP.With

theexceptionoTransmissionControlProtocol(TCP)signalingandUPnP,themethodsdescribedtakeadvantageo

signalingandmediasymmetryonalmostallnewerphones,andRefexiveUDPAdmissiononmostrewallsintheir

actualdeployedconguration.

Using TCP

UsingTCPorsignalingandconguringtheproxy(wherepossible)toignoremismatchingViaandContactheaders

causedbyNATstoacertainextentcanwork.However,toensurethatinboundcallscanreachclientsbehindrewalls,

persistentTCPconnectionsmustbemadewiththeproxy,whichdramaticallyreducesscalabilityandcreatesa

signicantamountonetworkoverhead.Furthermore,mostNATrewallshaveTCPidletimeouts,mandatingthe

useokeep-alivepacketsacrosstheTCPconnection.NotethatTCPonlyaddressessignaling,becauseRTPandRTCP

arestilltransmittedinUDP.

UPnP

UniversalPlugandPlay(UPnP)clientstrytosignaltheNATrewalltopre-allocatenumerousUDPportstoallowboth

incomingsignalandmedia.Inpractice,thereisotenconusionintheallocationotheseportswhenmorethanone

clienttriestoopenthesamerangeoUDPports.Sincealargepercentageorewallsarenotconguredtohave

UPnPenabled,onecannotrelyonUPnPtowork,especiallywhenusersmaynotknowwhethertherewallthey

arebehindisactuallyUPnPcompatible.


12/20



STUNSomeIPphonevendorsareimplementingSimpleTraversaloUDPthroughNAT(STUN),whichisinIETFDratstage

(RFC3489).STUNisaprotocolthatletsthephonequeryanexternalservertovalidateitsexternalIPaddress/port.

Unortunately,STUNdoesnotworkinthecommoncorporaterewallexampleoasymmetricNAT.

Inthisexamplebelow(seeFigure 10),thecallersendsasingleSTUNquerytogetitsRTPport(abridgedorthe

sakeosimplicity),whichistranslatedrom16384to1024.

Figure 10 : :STUNPortTranslation

Whenmakinganoutboundcall,thecaller(C1)sendsanINVITEto(C2)usingtheIPaddressandportinormationit

receivedromtheSTUNqueries(Figure 11).

Figure 11 : : STUNPortUsage

However,whenthetimecomesorthecallertosendmediatothecallee,theNATassignsanewportallocation.This

maybeduetotheactthattherewallchoosesadierentbindingoradierenthost(STUNservervs.callee),oritis

adierentbindingduetoadierentdestinationport(3478vs.8000inthisexample).


13/20



Figure 12below,displaysaschematicothisexample.Whenthecalleetriestosendmediatoport1024onthe

rewallbasedontheSDPinormation,itgetsblocked.

Figure 12 : :BlockedMedia

Furthermore,thereisnotellingwhethertheexternalhostwillsendmediasymmetrically.Manymediaserversor

voicemail,IVR,andconerencedonotsendandreceivemediaonthesameport.Thiscreatesamediaasymmetry

orwhichevenPort-restrictedConerewallswillnotwork.

NewerphonesotenexecuteaSTUNtesttonotiytheuserwhattypeoNATrewallthephoneisbehind.

However,sinceNATbindingscanchangeorexpirewithoutwarning,aSTUN-enabledphonebehindaNATrewall

shouldregularlyreconrmitsglobaladdressandportswiththeSTUNservers,andpreerablyrightbeoreitsendsa

requestsignal.Unortunately,thiscarriesthepenaltyoaddingloadtothenetwork.

Inrarecases,aRestrictedConeNATmayexhibitthebehavioroaSymmetricNAT.Thesesymptomsareobservable

whenaphonerequentlyre-registersromdierentglobalsourceports.Thismaybeduetotheinadvertentclearing

othetranslationtableorcongurationchangesthatmandatetherestartingotherewall,crashes,orsimplya

ailuretoollowthetranslationtimeoutsbasedoninactivity.

Ingeneral,STUNcanworkwell,butonlywhentheollowingcongurationexists:

TheSTUNclientisbehindaNATthatislessrestrictivethanaPort-restrictedCone,and

Thesignalingproxysignalssymmetrically,and

Theendpoint,ilocatedontheexternalnetwork,emits/receivesRTPsymmetrically, ortheotherendpointisa

STUNclient.

TURN

AsignicantsupplementtoSTUNthatutilizesanexternally-hostedMediaProxytodealwithsymmetricNATsis

TraversalUsingRelayNAT(TURN).ThegoaloTURNistoenablecallstopassthroughsymmetricNATs.


14/20



EndpointscouldbeequippedwiththeintelligencetonegotiatewiththeTURNservertoallocateandsendmedia

toaglobally-routablemediarelay.InsteadosendingmediabasedonSDPinormation,itrelaysmediaoreachcall

symmetrically,usingthesamesourceportonwhichitlistensorincomingmedia.

Amajorcriticismothisapproachistheamountobandwidthwastageandlatencyinducedbyroutingallmediato

acentralrendezvouslocation,andsubsequently,totheotherparty.Callsbetweentwoneighboringendpointsoten

ndtheirmediaroutedouttherewallandbackunnecessarily.

Signaling/Media Proxy Combination

TURNrequiresintelligencebuiltintotheendpointstosignalaTURNserver.Analternativeapproachistohavean

externalMediaProxythatoperatesinconjunctionwithaRegistrar/SignalingProxythatmodiesSDPascallsignals

passthrough.

Thisapproachdoesnotrequireendpointstohavetheintelligencetoperormanyglobaladdressdiscoveryorpre-call

signalingwithaTURNserver.AslongastheendpointssendandreceivemediasymmetricallyandtheNATsinvolved

supportrefexiveUDPadmission,thereshouldbenotroublegettingcallsthrough.

However,thisapproachsuersthesamedrawbackastheSTUN/TURNcombinationintermsobandwidtheciency

andscalability,andtheSIPproxyotenperormsunnecessaryre-routingomediabetweenclientsthatarenotbehind

rewallsorNATs.

ICE

InteractiveConnectivityEstablishment(ICE)isamethodthattriestobuildintelligenceintoendpointssothatthey

canperormroutediscovery,pathoptimization,andevenveriymediafowbeoreacallisdeemedtobeestablished.

PriortosendinganINVITE,thecallerperormsasequenceostepstocharacterizetherewallthatitisbehind:

Obtainsaddressesoallusableinteraces(local,VPN)

CheckstheresultsromSTUN

Ineeded,negotiatesaportwiththeTURNserver

Aterwards,thecallersendsalistoavailableIPaddresses/portsintheINVITEtotheproxy.

AssoonasthecalleegetstheINVITE,itollowsasimilarsetostepsasdidthecaller.Next,itattemptstosendSTUN

queriestothecallertoseeiitispossibletodirectlysendmediatoanyotheIPaddressesitpresentedintheINVITE.

Finally,thecalleepickstheaddressohighestpreerenceintheINVITEtowhichthecalleecancondentlysendmedia.

ThisapproachiscompatiblewithmostknownrewallsthatsupportUDP.InadditiontoworkingwithalltypesoNATsthatsupportrefexiveUDPadmission,italsoworkswiththeveryrestrictiverewallsthataredeliberately

conguredtoonlyallowinternalhoststoconverseusingUDPwithoneortwohostsontheoutside.However,or

ICEtoworkproperly,bothcallerandcalleemustsupportICE,andthereshouldreadilybeaSTUNandTURNserver

available.Forthisreason,itshouldbedeployedonlyinahomogeneous,controlledenvironment.Furthermore,it

islikelythatthecallsetupwillbedelayedbecauseothestepsinvolvedinmediapathdiscoverybyboththecaller

andcallee.

Finally,withtheendpointsadvertisingtheirowninternalIPaddresses,ICEmaynotmeetthetopologyhiding

requirementsosecurity-ocusedenvironments.


15/20



Using an External B2BUA/MPTheapproachesdiscussedthusarinthispapercanonlysolveselectedproblemssomeothetime.Furthermore,

theyotenrequireadditionalintelligenceontheendpoints,whichmaynotalwaysbeavailable.

Fortunately,anapproachhasbeendiscoveredthatworksinvirtuallyallsituationsthatdoesnotrequireanyadditional

customer-premiseequipment,sotware,orrewallconguration.TheresultoapplyingthisapproachisthatVoIP

signalingandmediastreamscanbemadetotraverseanarbitrarynumbero(possiblynested)NAT,PAT,andrewall

devices,usinganystandards-compliantendpoint.Thisapproachhastheaddedbenetthatinalmostallcases,no

additionalmediaworkloadorlatencyisintroduced,sincethemediastilltraveldirectlyromcallertocallee,and

viceversa.

ThisapproachinvolvestheuseoaSessionBorderController(SBC)thatcontainsaSIPBack-to-BackUserAgentwith

anembeddedMediaProxy(B2BUA/MP).TheB2BUA/MPislocatedintheserviceprovidersnetwork,romwhereit

canseeandreachtheglobalIPaddressesandportnumbersoallcallparticipants.Theendpointsinacallareset

uptoeitherregisterthroughtheB2BUA/MP,ortouseitastheiroutboundproxy(asperIETFRFC3261).Thejob

otheB2BUA/MPistoacceptcallsignalingandmediastreamsromendpointslocatedbehindNATdevices,andto

sanitizethosestreamssothattheycanbesenturtheroutontotheglobalInternet.Itisnotnecessaryorboth

endpointstobebehindthesameB2BUA/MP.Indeed,oneendpointcanbebehindoneandtheotherendpoint

behindanother,oroneendpointcanbebehindonewhiletheotherusessomeothermeanstodealwithitsownNAT

problems.Oneothemajoradvantagesothisapproachisthatitdoesnotrequireanyspecialdeviceorconguration

tobepresentatbothendsoacall.

Theollowingexample(Figure 13below)showshowaB2BUA,conguredastheoutboundproxyotheclient,can

unctionasaar-endNATtraversaldevice.

Figure 13 : :B2BUAasaNATTraversalDevice

TheregistrarproxynowhastheuserlocationinormationoC1attheB2BUA.Whenproperlyimplemented,the

B2BUAdoesnothavetokeepastaticallyprovisioneddatabaseousers,nordoestheproxyneedtobestatically

conguredwithuserlocationspointingattheB2BUA.


16/20



ToensurethatuserC1isalwaysreachableincaseoinboundcalls,theB2BUAusesvarioustypesoSIPsignalsto

encouragetheclientC1toregularlysendSIPtractotheB2BUA.ThisfowoSIPsignalsatregularintervalshelps

maintainthepinholeattherewall.IncaseoanunexpectedpinholeclosureorchangeinUDPstatebrought

aboutbyrewallanomalies,thisheartbeattracservestoinormtheB2BUAotheclientsnewgloballocation.

Topreventtheproxyrombeingoverwhelmedbythisheartbeattrac,thesignalsarenotpassedtotheproxy

unnecessarily.AsanadditionalmeasuretodealwithclientsthatdonotobeytherequestbytheB2BUAtosend

outboundmessages,theB2BUAinitiatesSIPmessagestoclientsperiodicallytoveriytheirrespectivelocations.

Whenproperlyimplemented,allthesignalsmentionedaboveshouldbegenericSIPsignalsthatshouldnotcause

anyproblemstoanySIPendpoints.

TheB2BUAalwaysusesthesameporttocommunicatewiththeclient,whichmakesitcompatiblewithsymmetric

NATs.UnlikeUPnP,wheretheclientopensmultipleportsacrosstherewallormultipleexternalhosts,thereisno

requirementortheclienttoopenadditionalpinholesacrosstherewall.

Whenacallisinitiated,theB2BUAmodiesthesignals,inormingboththecallerandcalleetosendtheirmedia

topre-allocatedportsonaMediaProxy,otenconguredtorunonthesamemachineastheB2BUA.Atregular

intervals,theB2BUAusesstandards-compliantSIPsignalstoveriythatbothcallerandcalleearestillonthecall.

Inthemostchallengingscenario,bothcallerandcalleeareeachbehindtheirownsymmetricNATs.SincetheMedia

Proxyisengagedatthestartothecall,bothpartiesreceivemediaromeachother,providedthateachsidehassent

atleastoneRTPpacket.Inourtheractionistakentooptimizethecall,thebehaviorotheB2BUAissimilartothe

Signaling/MediaProxycombinationmentionedearlierinthisdocument,havingthesamedrawbacksomedialatency

andbandwidthwastage.

UnlessonepartyonthecallisbehindasymmetricNATwithrequentporttranslationchanges,itispossibleto

re-directthemediaduringthemiddleoacall,wherethecallersendsthemediatothecorrectportontherewall

thathidesthecallee,andviceversa.ItisalsopossibleortheB2BUAtousestandards-compliantSIPsignalsto

characterizethetypeoNATrewallinrontoeachpartyonthecall.Thisisdonebyinspectingthecharacteristics

othemediafowatereachothoseNAT-characterizedsignalshasbeensent.ThistechniqueiscalledMediaPath

Optimization(MPO).Figure 14onpage17displaysaschematicotheprocessortheB2BUA/MP.


17/20



Figure 14 : :B2BUA/MPProcess

Figure 14displaystheollowingstepsintheB2BUA/MPprocess:

1. AssumingcalleeC2hasregistered,callerC1sendsanINVITE.

2. TheSIPproxyserver(Px)locatesC2attheB2BUA.

3. TheB2BUAsendsanINVITEtoC2sirewall.Notethatthesignalingprocessthatestablishesthecallhas

beenomittedhere.

4. Theinitialmedialowhasboththecallerandcalleesendingmediatothemediaproxy.

5. TheB2BUAnowstartsNATcharacterizationotheirewallsonbothsides.

6. TheB2BUAsendssignalstobothendpoints,tellingthemtosendthemediatospeciicportsontheother

partysirewall.

7.TheB2BUAsuccessullyremovesitselromthemediapath,butitstillmaintainscontrolocallsignaling.

Thekeydierentiatoroaport-translatingsymmetricNATromotherNATtypesisthatadierentglobal-to-local

port-mappingisusedithesameinternalhostsendsapacketwiththesamesourceaddressandport,buttoa

dierentdestinationhostordestinationport.ByobservingthechangesinmediabehaviorwitheverySIPsignal

senttoeachpartyonthecall,theMediaProxycandeterminewhetheraclientisbehindaport-translatingsymmetric

NAT.IeitherpartyisbehindsuchaNAT,theMediaProxymustcontinuetoproxythemediaorthecall.Fortunately,

thepercentageosymmetricNATsdeployedremainsrelativelysmall,especiallyinSmallOce/HomeOce(SOHO)

environments.AsideromNATcharacterization,SIPsignalsgeneratedbytheB2BUAmediapathoptimization

sequencealsohelptodeterminewhetherbothclientsonthecallaretolerantomediaredirection.


18/20



SinceNATcharacterizationisperormedaterthecallhasbeensetupandmediaisbeingreceivedbybothparties,

extremecaremustbetakentoavoidlossomediaduringtheprocedure.TheMediaProxyshouldnotdisengageitsel

untilacertaintimehaselapsedatermediapathoptimizationhascompleted,andbothclientsaresendingmediato

theotherpartysrespectiveglobaladdressandport.ItheMediaProxyeverdetectsanundesirablebehavioronthe

partotheclientorrewall,SIPsignalsshouldbegeneratedbytheB2BUAtoinormtheclientstorevertbacktothe

originalmediapath.

Additionally,thereareotherissuestobeconsideredwhenmediapathoptimizationisexecuted.TheB2BUAcannot

simplyattempttogloballyoptimizeallcalls.Someuseragentsdonotreactproperlytomediaredirectingandwillnot

sendmediatotheredirecteddestination.

ThereisalsotheissueowhethertohavethepartieswhoareapparentlybehindthesameNAPTaddresssend

mediatotherespectiveportsontheNATglobaladdress,orwhethertheyshouldsendmedialocallytoeachother.

AsignicantpercentageoNATswillnotrelayhairpinmediausingtheirglobalIPaddresses.Thatis,twohostson

theinternalsideotheNATmaynottalktoeachotherbyusingtheglobalIPaddressotheNAT.Ontheotherhand,

redirectingtheRTPfowtoeachpartyslocaladdressmaynotworkwellinthecasewherethereisonepartybehind

asecondlevelocascadedNATcallingapartylocatedinadierentcascadinglevel.Suchcasesmandatedisabling

mediapathoptimizationorcertainglobaladdresses,orusingslavemediarendezvouspointsstrategicallylocated

tominimizebandwidthwastage.

InadditiontoresolvingtheNATtraversalissues,anSBCwithaB2BUAcanprovideotherbenetsthatareoten

criticaltotheVoIPnetwork,suchas:

Topologyhiding

ProtectingserviceromDOSattacks EnorcingQoSpolicies

Ensuringend-to-endinteroperability

Billing

Per-sessiontroubleshooting

Lawulintercept

Summary

MostprovidersoIPtelephonyservicesbelievethattheexperienceoausershouldmirrortheeaseouseand

ubiquitousavailabilityothePublicSwitchedTelephoneNetwork(PSTN).Indeed,inmanycases,theeconomicso

providingservicerequirethatthingssimplyworksothatcustomersupportexpensesarekepttoaminimum.Given

thecomplexityotodaysNATandrewallprotectednetworksbothinresidentialandenterpriseenvironments

thiskindoubiquitousreliabilityorVoIPcanonlybesuccessullyprovidedwithsomehelpromaNATtraversal

system.Again,drivenmostlybyeconomics,suchasystemmustnotrequireanyspecialhardwareorsotwareonthe

userspremises,andmustnotrequireeithertheserviceproviderortheusertohaveanyspecialknowledgeothe

topologyothenetwork(orhowitsNATandrewallcomponentsaretobecongured).ThegoaloaNATtraversal

systemorreal-worlddeploymentmustthereorebetosolveusersNATandrewallproblemsremotely,androm

theserviceprovidersnetwork.


19/20



Manysolutionsinvolvingremotely-locatedNAThelperappliancessuchasSTUN,TURN,ICE,andUPnPhavebeenpro-

posed,buteachcanreasonablybedeployedonlyinasubsetosituationsthatistoosmalltobeopracticaluseora

ubiquitousservice.Ontheotherhand,theBack-to-BackUserAgentapproachwithitsembeddedMediaProxyworks

invirtuallyallsituations,andmeetsthegoalonotrequiringanyspecialand/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

DitechNetworksisaglobaltelecommunicationsequipmentsupplierorcommunicationsnetworks.DitechNetworks

voiceprocessingproductsservetheneedsomobileandwire-lineoperatorsorcircuit-andpacket-basednetworks.

Ditechproductsincludehigh-capacityvoiceenhancementandechocancellersolutionsthatutilizeadvancedsotware

anddigitalsignalprocessor(DSP)technology.ThiscombinationosotwareandhardwareallowsDitechNetworksto

deliverVoiceQualityAssurance(VQA)technology,arobustandcost-eectivesolutionorvoiceenhancementthat

includesbothnoisereductionandechocancellationtoprovideimprovedsoundqualityoncallsmadeoverwireless

networks.DitechNetworksVoIPproductscombineVQAtechnologywithpacketvoiceprocessingandsecurity

capabilitiestoenablecarrierstodeployend-to-endVoIPservicesacrossnetworksecurityboundarieswithout

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


20/20


Corporate HeadquartersUS Sales West

DitechNetworks

825EastMiddleieldRd.

MountainView,CA94043

USA

1-800-234-0884(TollFree)

1-650-623-1300(Direct)

1-650-564-9599(Fax)

[email protected]

US Sales Office East and Central

DitechNetworks

8360GreensboroDr.

McLean,VA22102USA

1-800-234-0884(TollFree)

1-650-623-1300(Direct)

1-650-564-9599(Fax)

[email protected]

Canada Sales Office

DitechNetworks

2275LakeshoreBlvdWest,Suite500

Toronto,ONM8V3Y3

Canada

1-416-255-7776(Phone)

[email protected]

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)

[email protected]

Brazil Sales Office

DitechNetworks

AlamedaAraguaia,933

Alphaville

Barueri,SP06455-000

Brazil

+55(11)4208-6266(Main)

+55(21)3521-5543(Sales)

[email protected]

[email protected]

China Sales Office

DitechNetworks

Unit3010,No.500XiangyangSouthRoad

XuhuiDistrict

Shanghai200031

PRC

+86(21)54560305(Phone)

[email protected]

South-East Asia Sales Office

DitechNetworks

LippoPlaza3rdFloor

Jl.Jend.SudirmanKav.25

Jakarta12920

Indonesia

+62(21)52913780(Phone)

+62(21)5221977(Fax)[email protected]

South Asia Sales Office

DitechNetworks

No.8/11,SarvapriyaVihar

NewDelhi110016

India

+919810372555(Phone)

[email protected]

Middle East/Africa Sales Office

DitechNetworks

21El-FawakehSt.,3rdFloor

Dokki,Giza12311

Egypt

+202336-5100(Phone)

+202761-8964(Fax)

[email protected]

Spain Sales Office

DitechNetworks

TorresQuevedo,1(P.T.M.)

28760TresCantosMadrid

Spain+34(91)8037444(Main)

+34(91)8292690(Sales)

[email protected]

[email protected]

Documents

WP Far End NAT Traversal