RFC 5853 - Requirements From Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments PDF

5/5/2015
RFC5853RequirementsfromSessionInitiationProtocol(SIP)SessionBorderControl(SBC)Deployments
InternetEngineeringTaskForce(IETF)J.Hautakorpi,Ed.
RequestforComments:5853G.Camarillo
Category:InformationalEricsson
ISSN:20701721R.Penfield
AcmePacket
A.Hawrylyshen
Skype,Inc.
M.Bhatia
3CLogic
April2010
RequirementsfromSessionInitiationProtocol(SIP)
SessionBorderControl(SBC)Deployments
Abstract
ThisdocumentdescribesfunctionsimplementedinSessionInitiation
Protocol(SIP)intermediariesknownasSessionBorderControllers
(SBCs).Thegoalofthisdocumentistodescribethecommonly
providedfunctionsofSBCs.Aspecialfocusisgiventothose
practicesthatareviewedtobeinconflictwithSIParchitectural
principles.Thisdocumentalsoexplorestheunderlyingrequirements
ofnetworkoperatorsthathaveledtotheuseofthesefunctionsand
practicesinordertoidentifyprotocolrequirementsanddetermine
whetherthoserequirementsaresatisfiedbyexistingspecifications
orifadditionalstandardsworkisrequired.
StatusofThisMemo
ThisdocumentisnotanInternetStandardsTrackspecification;itis
publishedforinformationalpurposes.
ThisdocumentisaproductoftheInternetEngineeringTaskForce
(IETF).ItrepresentstheconsensusoftheIETFcommunity.Ithas
receivedpublicreviewandhasbeenapprovedforpublicationbythe
InternetEngineeringSteeringGroup(IESG).Notalldocuments
approvedbytheIESGareacandidateforanylevelofInternet
Standard;seeSection2ofRFC5741.
Informationaboutthecurrentstatusofthisdocument,anyerrata,
andhowtoprovidefeedbackonitmaybeobtainedat
http://www.rfceditor.org/info/rfc5853.
https://tools.ietf.org/html/rfc5853
1/52
5/5/2015
Hautakorpi,etal.Informational[Page1]
2/52
5/5/2015
RFC5853RequirementsfromSIPSBCDeploymentsApril2010
CopyrightNotice
Copyright(c)2010IETFTrustandthepersonsidentifiedasthe
documentauthors.Allrightsreserved.
ThisdocumentissubjecttoBCP78andtheIETFTrust'sLegal
ProvisionsRelatingtoIETFDocuments
(http://trustee.ietf.org/licenseinfo)ineffectonthedateof
publicationofthisdocument.Pleasereviewthesedocuments
carefully,astheydescribeyourrightsandrestrictionswithrespect
tothisdocument.CodeComponentsextractedfromthisdocumentmust
includeSimplifiedBSDLicensetextasdescribedinSection4.eof
theTrustLegalProvisionsandareprovidedwithoutwarrantyas
describedintheSimplifiedBSDLicense.
3/52
5/5/2015
4/52
5/5/2015
TableofContents
1.Introduction....................................................4
2.BackgroundonSBCs..............................................4
2.1.PeeringScenario...........................................6
2.2.AccessScenario............................................6
3.FunctionsofSBCs...............................................8
3.1.TopologyHiding............................................8
3.1.1.GeneralInformationandRequirements................8
3.1.2.ArchitecturalIssues................................9
3.1.3.Example.............................................9
3.2.MediaTrafficManagement..................................11
3.2.1.GeneralInformationandRequirements...............11
3.2.2.ArchitecturalIssues...............................12
3.2.3.Example............................................13
3.3.FixingCapabilityMismatches..............................14
3.3.3.Example............................................15
3.4.MaintainingSIPRelatedNATBindings......................15
3.4.3.Example............................................17
3.5.AccessControl............................................18
3.5.3.Example............................................19
3.6.ProtocolRepair...........................................20
3.6.3.Examples...........................................21
3.7.MediaEncryption..........................................21
3.7.3.Example............................................22
4.DerivedRequirementsforFutureSIPStandardizationWork.......23
5.SecurityConsiderations........................................23
6.Acknowledgements...............................................24
7.References.....................................................25
7.1.NormativeReferences......................................25
7.2.InformativeReferences....................................25
5/52
5/5/2015
6/52
5/5/2015
1.Introduction
Inthepastfewyears,therehasbeenarapidadoptionoftheSession
InitiationProtocol(SIP)[1]anddeploymentofSIPbased
communicationsnetworks.Thishasoftenoutpacedthedevelopmentand
implementationofprotocolspecificationstomeetnetworkoperator
requirements.Thishasledtothedevelopmentofproprietary
solutions.Often,theseproprietarysolutionsareimplementedin
networkintermediariesknowninthemarketplaceasSessionBorder
Controllers(SBCs)becausetheytypicallyaredeployedattheborder
betweentwonetworks.Thereasonforthisisthatnetworkpolicies
aretypicallyenforcedattheedgeofthenetwork.
EventhoughmanySBCscurrentlybehaveinwaysthatcanbreakendto
endsecurityandimpactfeaturenegotiations,thereisclearlya
marketforthem.Networkoperatorsneedmanyofthefeaturescurrent
SBCsprovide,andoftentherearenostandardmechanismsavailableto
providethem.
Thepurposeofthisdocumentistodescribefunctionsimplementedin
SBCs.Aspecialfocusisgiventothosepracticesthatconflictwith
SIParchitecturalprinciplesinsomeway.Thedocumentalsoexplores
theunderlyingrequirementsofnetworkoperatorsthathaveledtothe
useofthesefunctionsandpracticesinordertoidentifyprotocol
requirementsanddeterminewhetherthoserequirementsaresatisfied
byexistingspecificationsorifadditionalstandardsworkis
required.
2.BackgroundonSBCs
ThetermSBCisrelativelynonspecific,sinceitisnotstandardized
ordefinedanywhere.NodesthatmaybereferredtoasSBCsbutdo
notimplementSIPareoutsidethescopeofthisdocument.
SBCsusuallysitbetweentwoserviceprovidernetworksinapeering
environment,orbetweenanaccessnetworkandabackbonenetworkto
provideservicetoresidentialand/orenterprisecustomers.They
provideavarietyoffunctionstoenableorenhancesessionbased
multimediaservices(e.g.,VoiceoverIP).Thesefunctionsinclude:
a)perimeterdefense(accesscontrol,topologyhiding,anddenialof
servicepreventionanddetection);b)functionalitynotavailablein
theendpoints(NATtraversal,protocolinterworkingorrepair);and
c)trafficmanagement(mediamonitoringandQualityofService
(QoS)).Someofthesefunctionsmayalsogetintegratedintoother
SIPelements(likeprepaidplatforms,ThirdGenerationPartnership
Project(3GPP)ProxyCSCF(PCSCF)[6],3GPPICSCF,etc.).
7/52
5/5/2015
8/52
5/5/2015
SIPbasedSBCstypicallyhandlebothsignalingandmediaandcan
implementbehaviorthatisequivalenttoa"privacyservice"(as
describedin[2])performingbothHeaderPrivacyandSession
Privacy).SBCsoftenmodifycertainSIPheadersandmessagebodies
thatproxiesarenotallowedtomodify.Consequently,theyare,by
definition,B2BUAs(BacktoBackUserAgents).Thetransparencyof
theseB2BUAsvariesdependingonthefunctionstheyperform.For
example,someSBCsmodifythesessiondescriptioncarriedinthe
messageandinsertaRecordRouteentry.OtherSBCsreplacethe
valueoftheContactheaderfieldwiththeSBCs'addressandgenerate
anewCallIDandnewToandFromtags.
++
|SBC|
[signaling]|++|
<|>|signaling|<|>
outer|++|inner
network|||network
|++|
<|>|media|<|>
[media]|++|
++
Figure1:SBCArchitecture
Figure1showsthelogicalarchitectureofanSBC,whichincludesa
signalingandamediacomponent.Inthisdocument,thetermsouter
andinnernetworkareusedfordescribingthesetwonetworks.AnSBC
islogicallyassociatedwiththeinnernetwork,andittypically
providesfunctionssuchascontrollingandprotectingaccesstothe
innernetworkfromtheouternetwork.TheSBCitselfisconfigured
andmanagedbytheorganizationoperatingtheinnernetwork.
Insomescenarios,SBCsoperatewithusers'(implicitorexplicit)
consent;whileinothers,theyoperatewithoutusers'consent(this
lattercasecanpotentiallycauseproblems).Forexample,ifanSBC
inthesameadministrativedomainasasetofenterpriseusers
performstopologyhiding(seeSection3.1),theenterpriseuserscan
choosetoroutetheirSIPmessagesthroughit.Iftheychooseto
routethroughtheSBC,thentheSBCcanbeseenashavingtheusers'
implicitconsent.Anotherexampleisascenariowhereaservice
providerhasbrokengatewaysanditdeploysanSBCinfrontofthem
forprotocolrepairreasons(seeSection3.6).Userscanchooseto
configuretheSBCastheirgatewayand,so,theSBCcanbeseenas
havingtheusers'implicitconsent.
9/52
5/5/2015
10/52
5/5/2015
2.1.PeeringScenario
Atypicalpeeringscenarioinvolvestwonetworkoperatorswho
exchangetrafficwitheachother.Anexamplepeeringscenariois
illustratedinFigure2.Anoriginatinggateway(GWA1)inOperator
A'snetworksendsanINVITEthatisroutedtotheSBCinOperatorB's
network.Then,theSBCforwardittothesoftswitch(SSB).The
softswitchrespondswitharedirect(3xx)messagebacktotheSBC
thatpointstotheappropriateterminatinggateway(GWB1)in
OperatorB'snetwork.IfOperatorBdoesnothaveanSBC,the
redirectmessagewouldgototheOperatorA'soriginatinggateway.
Afterreceivingtheredirectmessage,theSBCsendstheINVITEtothe
terminatinggateway.
OperatorA.OperatorB
.
.2)INVITE
++./>++
|SSA|./3)3xx(redir.)|SSB|
++.//++
.//
++1)INVITE++//++
|GWA1|>|SBC|</4)INVITE|GWB1|
++++>++
.
++.++
|GWA2|.|GWB2|
++.++
Figure2:PeeringwithSBC
FromtheSBC'sperspectivetheOperatorAistheouternetwork,and
OperatorBistheinnernetwork.OperatorBcanusetheSBC,for
example,tocontrolaccesstoitsnetwork,protectitsgatewaysand
softswitchesfromunauthorizeduseanddenialofservice(DoS)
attacks,andmonitorthesignalingandmediatraffic.Italso
simplifiesnetworkmanagementbyminimizingthenumberofACL(Access
ControlList)entriesinthegateways.Thegatewaysdonotneedto
beexposedtothepeernetwork,andtheycanrestrictaccess(both
mediaandsignaling)totheSBCs.TheSBChelpsensurethatonly
mediafromsessionstheSBCauthorizeswillreachthegateway.
2.2.AccessScenario
Inanaccessscenario,presentedinFigure3,theSBCisplacedat
theborderbetweentheaccessnetwork(outernetwork)andthe
operator'snetwork(innernetwork)tocontrolaccesstothe
operator'snetwork,protectitscomponents(mediaservers,
11/52
5/5/2015
12/52
5/5/2015
applicationservers,gateways,etc.)fromunauthorizeduseandDoS
attacks,andmonitorthesignalingandmediatraffic.Also,since
theSBCiscallstateful,itmayprovideaccesscontrolfunctionsto
preventoversubscriptionoftheaccesslinks.Endpointsare
configuredwiththeSBCastheiroutboundproxyaddress.TheSBC
routesrequeststooneormoreproxiesintheoperatornetwork.
AccessNetworkOperatorNetwork
++
|UA1|<\
++\
\
++\>++++
|UA2|<>|SBC|<>|proxy|<
++/>++++
/
++++/
|UA3++NAT|</
++++
Figure3:AccessScenariowithSBC
TheSBCmaybehostedintheaccessnetwork(e.g.,thisiscommon
whentheaccessnetworkisanenterprisenetwork),orintheoperator
network(e.g.,thisiscommonwhentheaccessnetworkisa
residentialorsmallbusinessnetwork).DespitewheretheSBCis
hosted,itismanagedbytheorganizationmaintainingtheoperator
network.
SomeendpointsmaybebehindenterpriseorresidentialNATs.In
caseswheretheaccessnetworkisaprivatenetwork,theSBCisaNAT
foralltraffic.ItisnoteworthythatSIPtrafficmayhaveto
traversemorethanoneNAT.Theproxyusuallydoesauthentication
and/orauthorizationforregistrationsandoutboundcalls.TheSBC
modifiestheREGISTERrequestsothatsubsequentrequeststothe
registeredaddressofrecordareroutedtotheSBC.Thisisdone
eitherwithaPathheaderfield[3]orbymodifyingtheContactto
pointattheSBC.
Thescenariopresentedinthissectionisageneralone,andit
appliesalsotoothersimilarsettings.Oneexamplefromasimilar
settingistheonewhereanaccessnetworkistheopeninternet,and
theoperatornetworkisthenetworkofaSIPserviceprovider.
13/52
5/5/2015
14/52
5/5/2015
3.FunctionsofSBCs
ThissectionliststhosefunctionsthatareusedinSBCdeployments
incurrentcommunicationnetworks.Eachsubsectiondescribesa
particularfunctionorfeature,theoperators'requirementsfor
havingit,explanationofanyimpacttotheendtoendSIP
architecture,andaconcreteimplementationexample.Eachsection
alsodiscussespotentialconcernsspecifictothatparticular
implementationtechnique.Suggestionsforalternativeimplementation
techniquesthatmaybemorearchitecturallycompatiblewithSIPare
outsidethescopeofthisdocument.
Alltheexamplesgiveninthissectionaresimplified;onlythe
relevantheaderlinesfromSIPandSDP(SessionDescriptionProtocol)
[7]messagesaredisplayed.
3.1.TopologyHiding
3.1.1.GeneralInformationandRequirements
Topologyhidingconsistsoflimitingtheamountoftopology
informationgiventoexternalparties.Operatorshavearequirement
forthisfunctionalitybecausetheydonotwanttheIPaddressesof
theirequipment(proxies,gateways,applicationservers,etc.)tobe
exposedtooutsideparties.Thismaybebecausetheydonotwantto
exposetheirequipmenttoDoSattacks,theymayuseothercarriers
forcertaintrafficanddonotwanttheircustomerstobeawareof
it,ortheymaywanttohidetheirinternalnetworkarchitecturefrom
competitorsorpartners.Insomeenvironments,theoperator's
customersmaywishtohidetheaddressesoftheirequipmentorthe
SIPmessagesmaycontainprivate,nonroutableaddresses.
Themostcommonformoftopologyhidingistheapplicationofheader
privacy(seeSection5.1of[2]),whichinvolvesstrippingViaand
RecordRouteheaders,replacingtheContactheader,andevenchanging
CallIDs.However,indeploymentsthatuseIPaddressesinsteadof
domainnamesinheadersthatcannotberemoved(e.g.,FromandTo
headers),theSBCmayreplacetheseIPaddresseswithitsownIP
addressordomainname.
Forareference,therearealsootherwaysofhidingtopology
informationthaninsertinganintermediary,likeanSBC,tothe
signalingpath.OneofthewaysistheUAdrivenprivacymechanism
[8],wheretheUAcanfacilitatetheconcealmentoftopology
information.
15/52
5/5/2015
16/52
5/5/2015
3.1.2.ArchitecturalIssues
Performingtopologyhiding,asdescribedabove,bySBCsthatdonot
havetheusers'consentpresentssomeissues.Thisfunctionalityis
basedonahopbyhoptrustmodelasopposedtoanendtoendtrust
model.Themessagesaremodifiedwithoutthesubscriber'sconsent
andcouldpotentiallymodifyorremoveinformationabouttheuser's
privacy,securityrequirements,andhigherlayerapplicationsthat
arecommunicatedendtoendusingSIP.Neitheruseragentinanend
toendcallhasanywaytodistinguishtheSBCactionsfromamanin
themiddle(MITM)attack.
ThetopologyhidingfunctiondoesnotworkwellwithAuthenticated
IdentityManagement[4]inscenarioswheretheSBCdoesnothaveany
kindofconsentfromtheusers.TheAuthenticatedIdentity
Managementmechanismisbasedonahashvaluethatiscalculatedfrom
partsofFrom,To,CallID,CSeq,Date,andContactheaderfields
plusfromthewholemessagebody.Iftheauthenticationserviceis
notprovidedbytheSBCitself,themodificationofthe
aforementionedheaderfieldsandthemessagebodyisinviolationof
[4].Someformsoftopologyhidingareinviolation,becausethey
are,e.g.,replacingtheContactheaderofaSIPmessage.
3.1.3.Example
Thecurrentwayofimplementingtopologyhidingconsistsofhavingan
SBCactasaB2BUA(BacktoBackUserAgent)andremovealltracesof
topologyinformation(e.g.,ViaandRecordRouteentries)from
outgoingmessages.
Imaginethefollowingexamplescenario:theSBC
(p4.domain.example.com)receivesanINVITErequestfromtheinner
network,whichinthiscaseisanoperatornetwork.ThereceivedSIP
messageisshowninFigure4.
17/52
5/5/2015
18/52
5/5/2015
INVITEsip:callee@u2.domain.example.comSIP/2.0
Via:SIP/2.0/UDPp3.middle.example.com;branch=z9hG4bK48jq9w174131.1
Via:SIP/2.0/UDPp2.example.com;branch=z9hG4bK18an6i9234172.1
Via:SIP/2.0/UDPp1.example.com;branch=z9hG4bK39bn2e5239289.1
Via:SIP/2.0/UDPu1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact:sip:caller@u1.example.com
RecordRoute:<sip:p3.middle.example.com;lr>
RecordRoute:<sip:p2.example.com;lr>
RecordRoute:<sip:p1.example.com;lr>
Figure4:INVITERequestPriortoTopologyHiding
Then,theSBCperformsatopologyhidingfunction.Inthisscenario,
theSBCremovesandstoresallexistingViaandRecordRouteheaders,
andtheninsertsViaandRecordRouteheaderfieldswithitsownSIP
URI.Afterthetopologyhidingfunction,themessagecouldappearas
showninFigure5.
INVITEsip:callee@u2.domain.example.comSIP/2.0
Via:SIP/2.0/UDPp4.domain.example.com;branch=z9hG4bK92es3w230129.1
RecordRoute:<sip:p4.domain.example.com;lr>
Figure5:INVITERequestafterTopologyHiding
LikearegularproxyserverthatinsertsaRecordRouteentry,the
SBChandleseverysinglemessageofagivenSIPdialog.IftheSBC
losesstate(e.g.,SBCrestartsforsomereason),itmaynotbeable
toroutemessagesproperly(note:someSBCspreservethestate
informationalsoonrestart).Forexample,iftheSBCremovesVia
entriesfromarequestandthenrestarts,thuslosingstate;theSBC
maynotbeabletorouteresponsestothatrequest,dependingonthe
informationthatwaslostwhentheSBCrestarted.
Thisisonlyoneexampleoftopologyhiding.Besidestopologyhiding
(i.e.,informationrelatedtothenetworkelementsisbeinghidden),
SBCsmayalsodoidentityhiding(i.e.,informationrelatedto
identityofsubscribersisbeinghidden).Whileperformingidentity
hiding,SBCsmaymodifyContactheaderfieldvaluesandotherheader
fieldscontainingidentityinformation.Theheaderfieldscontaining
identityinformationislistedinSection4.1of[2].Sincethe
publicationof[2],thefollowingheaderfieldscontainingidentity
informationhavebeendefined:"PAssertedIdentity","ReferredBy",
"Identity",and"IdentityInfo".
19/52
5/5/2015
20/52
5/5/2015
3.2.MediaTrafficManagement
Mediatrafficmanagementisthefunctionofcontrollingmedia
traffic.Networkoperatorsmayrequirethisfunctionalityinorder
tocontrolthetrafficbeingcarriedontheirnetworkonbehalfof
theirsubscribers.Trafficmanagementhelpsthecreationof
differentkindsofbillingmodels(e.g.,videotelephonycanbe
priceddifferentlythanvoiceonlycalls)anditalsomakesit
possibleforoperatorstoenforcetheusageofselectedcodecs.
Oneoftheusecasesformediatrafficmanagementisthe
implementationofinterceptcapabilitiesthatarerequiredtosupport
auditorlegalobligations.Itisnoteworthythatthelegal
obligationsmainlyapplytooperatorsprovidingvoiceservices,and
thoseoperatorstypicallyhaveinfrastructure(e.g.,SIPproxies
actingasB2BUAs)forprovidinginterceptcapabilitiesevenwithout
SBCs.
Sincethemediapathisindependentofthesignalingpath,themedia
maynottraversethroughtheoperator'snetworkunlesstheSBC
modifiesthesessiondescription.Bymodifyingthesession
description,theSBCcanforcethemediatobesentthroughamedia
relaywhichmaybecolocatedwiththeSBC.Thiskindoftraffic
managementcanbedone,forexample,toensureacertainQoSlevel,
ortoensurethatsubscribersareusingonlyallowedcodecs.Itis
noteworthythattheSBCsdonothavedirecttiestoroutingtopology
andtheydonot,forexample,changebandwidthreservationson
TrafficEngineering(TE)tunnels,nordotheyhavedirectinteraction
withroutingprotocol.
Someoperatorsdonotwanttomanagethetraffic,butonlytomonitor
ittocollectstatisticsandmakesurethattheyareabletomeetany
businessservicelevelagreementswiththeirsubscribersand/or
partners.Theprotocoltechniques,fromtheSBC'sviewpoint,needed
formonitoringmediatrafficarethesameasformanagingmedia
traffic.
SBCsonthemediapatharealsocapableofdealingwiththe"lost
BYE"issueifeitherendpointdiesinthemiddleofthesession.The
SBCcandetectthatthemediahasstoppedflowingandissueaBYEto
bothsidestocleanupanystateinotherintermediateelementsand
theendpoints.
OnepossibleformofmediatrafficmanagementisthatSBCsterminate
mediastreamsandSIPdialogsbygeneratingBYErequests.Thiskind
ofprocedurecantakeplace,forexample,inasituationwherethe
21/52
5/5/2015
22/52
5/5/2015
subscriberrunsoutofcredits.Mediamanagementisneededtoensure
thatthesubscribercannotjustignoretheBYErequestgeneratedby
theSBCandcontinueitsmediasessions.
ImplementingtrafficmanagementinthismannerrequirestheSBCto
accessandmodifythesessiondescriptions(i.e.,offersandanswers)
exchangedbetweentheuseragents.Consequently,thisapproachdoes
notworkifuseragentsencryptorintegrityprotecttheirmessage
bodiesendtoend.Again,messagesaremodifiedwithoutsubscriber
consent,anduseragentsdonothaveanywaytodistinguishtheSBC
actionsfromanattackbyaMITM.Furthermore,thisisinviolation
ofAuthenticatedIdentityManagement[4],seeSection3.1.2.
Theinsertionofamediarelaycanprevent"nonmedia"usesofthe
mediapath,forexample,themediapathkeyagreement.Sometimes
thistypeofpreventionisintentional,butitisnotalways
necessary.Forexample,ifanSBCisusedjustforenablingmedia
monitoring,butnotforinterception.
Therearesomepossibleissuesrelatedtothemediarelaying.Ifthe
mediarelayingisnotdoneinthecorrectmanner,itmaybreak
functionslikeExplicitCongestionNotification(ECN)andPathMTU
Discovery(PMTUD),forexample.Themediarelayseasilybreaksuch
IPandtransportlayerfunctionalitiesthatrelyonthecorrect
handlingoftheprotocolfields.Someespeciallysensitivefields
are,forexample,ECNandTypeofService(ToS)fieldsandtheDon't
Fragment(DF)bit.
Thewayinwhichmediatrafficmanagementfunctionsimpedes
innovation.Thereasonfortheimpedimentisthatinmanycases,
SBCsneedtobeabletosupportnewformsofcommunication(e.g.,
extensionstotheSDPprotocol)beforenewservicescanbeputinto
use,whichslowstheadoptionofnewinnovations.
IfanSBCdirectsmanymediastreamsthroughacentralpointinthe
network,itislikelytocauseasignificantamountofadditional
traffictoapathtothatcentralpoint.Thismightcreatepossible
bottleneckinthepath.
Inthisapplication,theSBCmayoriginatemessagesthattheusermay
notbeabletoauthenticateascomingfromthedialogpeerortheSIP
Registrar/Proxy.
23/52
5/5/2015
24/52
5/5/2015
3.2.3.Example
Trafficmanagementmaybeperformedinthefollowingway:TheSBC
behavesasaB2BUAandinsertsitself,orsomeotherentityunderthe
operator'scontrol,inthemediapath.Inpractice,theSBCmodifies
thesessiondescriptionscarriedintheSIPmessages.Asaresult,
theSBCreceivesmediafromoneuseragentandrelaysittotheother
useragentandperformstheidenticaloperationwithmediatraveling
inthereversedirection.
AsmentionedinSection3.2.1,codecrestrictionisaformoftraffic
management.TheSBCrestrictsthecodecsetnegotiatedintheoffer/
answerexchange[5]betweentheuseragents.Aftermodifyingthe
sessiondescriptions,theSBCcancheckwhetherornotthemedia
streamcorrespondstowhatwasnegotiatedintheoffer/answer
exchange.Ifitdiffers,theSBChastheabilitytoterminatethe
mediastreamortakeotherappropriate(configured)actions(e.g.,
raiseanalarm).
Considerthefollowingexamplescenario:theSBCreceivesanINVITE
requestfromtheouternetwork,whichinthiscaseisanaccess
network.ThereceivedSIPmessagecontainstheSDPsession
descriptorshowninFigure6.
v=0
o=owner28908445262890842807INIP4192.0.2.4
c=INIP4192.0.2.4
m=audio49230RTP/AVP9698
a=rtpmap:96L8/8000
a=rtpmap:98L16/16000/2
Figure6:RequestPriortoMediaManagement
Inthisexample,theSBCperformsthemediatrafficmanagement
functionbyrewritingthe"m="line,andremovingone"a="line
accordingtosome(external)policy.Figure7showsthesession
descriptionafterthetrafficmanagementfunction.
v=0
o=owner28908445262890842807INIP4192.0.2.4
c=INIP4192.0.2.4
a=rtpmap:96L8/8000
Figure7:RequestBodyAfterMediaManagement
25/52
5/5/2015
26/52
5/5/2015
MediatrafficmanagementhasaproblemwheretheSBCneedsto
understandthesessiondescriptionprotocolandallextensionsused
bytheuseragents.Thismeansthatinordertouseanewextension
(e.g.,anextensiontoimplementanewservice)oranewsession
descriptionprotocol,SBCsinthenetworkmayneedtobeupgradedin
conjunctionwiththeendpoints.Itisnoteworthythatasimilar
problem,butwithheaderfields,appliesto,forexample,topology
hidingfunction,seeSection3.1.Certainextensionsthatdonot
requireactivemanipulationofthesessiondescriptorstofacilitate
trafficmanagementwillbeabletobedeployedwithoutupgrading
existingSBCs,dependingonthedegreeoftransparencytheSBC
implementationaffords.IncasesrequiringanSBCmodificationto
supportthenewprotocolfeatures,therateofservicedeploymentmay
beaffected.
3.3.FixingCapabilityMismatches
SBCsfixingcapabilitymismatchesenablecommunicationsbetweenuser
agentswithdifferentcapabilitiesorextensions.Forexample,an
SBCcanenableaplainSIP[1]useragenttoconnecttoa3GPP
network,orenableaconnectionbetweenuseragentsthatsupport
differentIPversions,differentcodecs,orthatareindifferent
addressrealms.Operatorshavearequirementandastrongmotivation
forperformingcapabilitymismatchfixing,sothattheycanprovide
transparentcommunicationacrossdifferentdomains.Insomecases,
differentSIPextensionsormethodstoimplementthesameSIP
application(likemonitoringsessionliveness,callhistory/diversion
etc.)mayalsobeinterworkedthroughtheSBC.
SBCsthatarefixingcapabilitymismatchesdoitbyinsertingamedia
elementintothemediapathusingtheproceduresdescribedin
Section3.2.Therefore,theseSBCshavethesameconcernsasSBCs
performingtrafficmanagement:theSBCmaymodifySIPmessages
withoutconsentfromanyoftheuseragents.Thismaybreakendto
endsecurityandapplicationextensionsnegotiation.
Thecapabilitymismatchfixingisafragilefunctioninthelong
term.Thenumberofincompatibilitiesbuiltintovariousnetwork
elementsisincreasingthefragilityandcomplexityovertime.This
mightleadtoasituationwhereSBCsneedtobeabletohandlea
largenumberofcapabilitymismatchesinparallel.
27/52
5/5/2015
28/52
5/5/2015
3.3.3.Example
Considerthefollowingexamplescenariowheretheinnernetworkisan
accessnetworkusingIPv4andtheouternetworkisusingIPv6.The
SBCreceivesanINVITErequestwithasessiondescriptionfromthe
accessnetwork:
INVITEsip:callee@ipv6.domain.example.comSIP/2.0
Via:SIP/2.0/UDP192.0.2.4
v=0
o=owner28908445262890842807INIP4192.0.2.4
c=INIP4192.0.2.4
a=rtpmap:96L8/8000
Figure8:RequestPriortoCapabilitiesMatch
Then,theSBCperformsacapabilitymismatchfixingfunction.In
thisscenario,theSBCinsertsRecordRouteandViaheadersand
rewritesthe"c="linefromthesessionsdescriptor.Figure9shows
therequestafterthecapabilitymismatchadjustment.
INVITEsip:callee@ipv6.domain.comSIP/2.0
RecordRoute:<sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>
Via:SIP/2.0/UDPsip:[2001:DB8::801:201:2ff:fe94:8e10]
Via:SIP/2.0/UDP192.0.2.4
v=0
o=owner28908445262890842807INIP4192.0.2.4
c=INIP62001:DB8::801:201:2ff:fe94:8e10
a=rtpmap:96L8/8000
Figure9:RequestafterCapabilityMatch
ThismessageisthensentbytheSBCtotheonwardIPv6network.
3.4.MaintainingSIPRelatedNATBindings
NATtraversalinthisinstancereferstothespecificmessage
modificationsrequiredtoassistauseragentinmaintainingSIPand
mediaconnectivitywhenthereisaNATdevicelocatedbetweenauser
agentandaproxy/registrarand,possibly,anyotheruseragent.The
29/52
5/5/2015
30/52
5/5/2015
primarypurposeofNATtraversalfunctionistokeepupacontrol
connectiontouseragentsbehindNATs.Thiscan,forexample,be
achievedbygeneratingperiodicnetworktrafficthatkeepsbindings
inNATsalive.SBCs'NATtraversalfunctionisrequiredinscenarios
wheretheNATisoutsidetheSBC(i.e.,notincaseswhereSBCitself
actsasaNAT).
AnSBCperformingaNAT(NetworkAddressTranslator)traversal
functionforauseragentbehindaNATsitsbetweentheuseragent
andtheregistrarofthedomain.NATsarewidelydeployedinvarious
accessnetworkstoday,sooperatorshavearequirementtosupportit.
WhentheregistrarreceivesaREGISTERrequestfromtheuseragent
andrespondswitha200(OK)response,theSBCmodifiessucha
responsedecreasingthevalidityoftheregistration(i.e.,the
registrationexpiressooner).Thisforcestheuseragenttosenda
newREGISTERtorefreshtheregistrationsoonerthatitwouldhave
doneonreceivingtheoriginalresponsefromtheregistrar.The
REGISTERrequestssentbytheuseragentrefreshthebindingofthe
NATbeforethebindingexpires.
NotethattheSBCdoesnotneedtorelayalltheREGISTERrequests
receivedfromtheuseragenttotheregistrar.TheSBCcangenerate
responsestoREGISTERrequestsreceivedbeforetheregistrationis
abouttoexpireattheregistrar.Moreover,theSBCneedsto
deregistertheuseragentifthisfailstorefreshitsregistration
intime,eveniftheregistrationattheregistrarwouldstillbe
valid.
SBCscanalsoforcetraffictogothroughamediarelayforNAT
traversalpurposes(moreaboutmediatrafficmanagementin
Section3.2).Atypicalcallhasmediastreamstotwodirections.
EventhoughSBCscanforcemediastreamsfrombothdirectionstogo
throughamediarelay,insomecases,itisenoughtorelayonlythe
mediafromonedirection(e.g.,inascenariowhereonlytheother
endpointisbehindaNAT).
ThisapproachtoNATtraversaldoesnotworkifendtoend
confidentialityorintegrityprotectionmechanismsareused(e.g.,
Secure/MultipurposeInternetMailExtensions(S/MIME)).TheSBC
wouldbeseenasaMITMmodifyingthemessagesbetweentheuseragent
andtheregistrar.
ThereisalsoaproblemrelatedtothemethodofhowSBCschoosethe
valueforthevalidityofaregistrationperiod.Thisvalueshould
beashighaspossible,butitstillneedstobelowenoughto
maintaintheNATbinding.SomeSBCsdonothaveanydeterministic
31/52
5/5/2015
32/52
5/5/2015
methodforchoosingasuitablevalue.However,SBCscanjustusea
suboptimal,relativelysmallvaluethatusuallyworks.Anexample
fromsuchvalueis15seconds(see[9]).
NATtraversalformediausingSBCsposesfewissuesaswell.For
example,anSBCnormallyguessestherecipient'spublicIPaddresson
oneofthemediastreamsrelayedbytheSBCbysnoopingonthesource
IPaddressofanothermediastreamrelayedbythesameSBC.This
causessecurityandinteroperabilityissuessincetheSBCcanendup
associatingwrongdestinationIPaddressesonmediastreamsitis
relaying.Forexample,anattackermaysnooponthelocalIPaddress
andportsusedbytheSBCformediarelayingthestreamsandsenda
fewpacketsfromamaliciousIPaddresstothesedestinations.In
mostcases,thiscancausemediastreamsintheoppositedirections
todiverttraffictotheattackerresultinginasuccessfulMITMor
DoSattack.Asimilarexampleofaninteroperabilityissueiscaused
whenanendpointbehindaNATattemptstoswitchtheIPaddressof
themediastreamsbyusingareINVITE.Ifanymediapacketsarere
orderedordelayedinthenetwork,theycancausetheSBCtoblock
theswitchfromhappeningevenifthereINVITEsuccessfullygoes
through.
3.4.3.Example
Considerthefollowingexamplescenario:TheSBCresidesbetweenthe
UAandRegistrar.Previously,theUAhassentaREGISTERrequestto
theRegistrar,andtheSBCreceivestheregistrationresponseshown
inFigure10.
SIP/2.0200OK
From:Bob<sip:bob@biloxi.example.com>;tag=a73kszlfl
To:Bob<sip:bob@biloxi.example.com>;tag=34095828jh
CSeq:1REGISTER
Contact:<sips:bob@client.biloxi.example.com>;expires=3600
Figure10:ResponsePriortoNATMaintenanceFunction
WhenperformingtheNATtraversalfunction,theSBCmayrewritethe
expirytimetocoaxtheUAtoreregisterpriortotheintermediating
NATdecidingtoclosethepinhole.Figure11showsapossible
modificationoftheresponsefromFigure10.
33/52
5/5/2015
34/52
5/5/2015
SIP/2.0200OK
From:Bob<sip:bob@biloxi.example.com>;tag=a73kszlfl
To:Bob<sip:bob@biloxi.example.com>;tag=34095828jh
CSeq:1REGISTER
Contact:<sips:bob@client.biloxi.example.com>;expires=60
Figure11:ManipulatedResponseforNATTraversal
Naturally,othermeasurescouldbetakeninordertoenabletheNAT
traversal(e.g.,nonSIPkeepalivemessages),butthisexample
illustratesonlyonemechanismforpreservingtheSIPrelatedNAT
bindings.
3.5.AccessControl
Networkoperatorsmaywishtocontrolwhatkindofsignalingand
mediatraffictheirnetworkcarries.Thereisstrongmotivationand
arequirementtodoaccesscontrolontheedgeofanoperator's
network.Accesscontrolcanbebasedon,forexample,linklayer
identifiers,IPaddressesorSIPidentities.
Thisfunctioncanbeimplementedbyprotectingtheinnernetworkwith
firewallsandconfiguringthemsothattheyonlyacceptSIPtraffic
fromtheSBC.Thisway,alltheSIPtrafficenteringtheinner
networkneedstoberoutedthoughtheSBC,whichonlyroutesmessages
fromauthorizedpartiesortrafficthatmeetsaspecificpolicythat
isexpressedintheSBCadministratively.
Accesscontrolcanbeappliedtoeitheronlythesignalingorboth
thesignalingandmedia.Ifitisappliedonlytothesignaling,
thentheSBCmightbehaveasaproxyserver.Ifaccesscontrolis
appliedtoboththesignalingandmedia,thentheSBCbehavesina
similarmannerasexplainedinSection3.2.Akeypartofmedia
layeraccesscontrolisthatonlymediaforauthorizedsessionsis
allowedtopassthroughtheSBCand/orassociatedmediarelay
devices.
Operatorsimplementsomefunctionalities,likeNATtraversalfor
example,inanSBCinsteadofotherelementsintheinnernetworkfor
severalreasons:(i)preventingpacketsfromunregisteredusersto
preventchancesofDoSattack,(ii)prioritizationand/orrerouting
oftraffic(basedonuserorservice,likeE911)asitentersthe
network,and(iii)performingaloadbalancingfunctionorreducing
theloadonothernetworkequipment.
35/52
5/5/2015
36/52
5/5/2015
Inenvironmentswherethereislimitedbandwidthontheaccesslinks,
theSBCcancomputethepotentialbandwidthusebyexaminingthe
codecspresentinSDPoffersandanswers.Withthisinformation,the
SBCcanrejectsessionsbeforetheavailablebandwidthisexhausted
toallowexistingsessionstomaintainacceptablequalityofservice.
Otherwise,thelinkcouldbecomeoversubscribedandallsessions
wouldexperienceadeteriorationinqualityofservice.SBCsmay
contactapolicyservertodeterminewhethersufficientbandwidthis
availableonapersessionbasis.
SincetheSBCneedstohandleallSIPmessages,thisfunctionhas
scalabilityimplications.Inaddition,theSBCisasinglepointof
failurefromanarchitecturalpointofview.Although,inpractice,
manycurrentSBCshavethecapabilitytosupportredundant
configuration,whichpreventsthelossofcallsand/orsessionsin
theeventofafailureonasinglenode.
Ifaccesscontrolisperformedonlyonbehalfofsignaling,thenthe
SBCiscompatiblewithgeneralSIParchitecturalprinciples,butif
itisperformedforsignalingandformedia,thentherearesimilar
problemsasdescribedinSection3.2.2.
3.5.3.Example
Figure12showsacallflowwheretheSBCisprovidingbothsignaling
andmediaaccesscontrol(ACKsomittedforbrevity).
37/52
5/5/2015
38/52
5/5/2015
callerSBCcallee
|||
|Identifythecaller||
|<>||
|||
|INVITE+SDP||
|>||
|[ModifytheSDP]|
||INVITE+modifiedSDP|
||>|
|||
||200OK+SDP|
||<|
|[ModifytheSDP]|
|||
|200OK+modifiedSDP||
|<||
|||
|Media[Mediainspection]Media|
|<======================>|<======================>|
|||
Figure12:ExampleAccessCallflow
Inthisscenario,theSBCfirstidentifiesthecaller,soitcan
determinewhetherornottogivesignalingaccesstothecaller.
Thismightbeachievedusinginformationgatheredduring
registration,orbyothermeans.SomeSBCsmayrelyontheproxyto
authenticatetheuseragentplacingthecall.Afteridentification,
theSBCmodifiesthesessiondescriptorsinINVITEand200OK
messagesinawaysothatthemediaisgoingtoflowthroughtheSBC
itself.Whenthemediastartsflowing,theSBCcaninspectwhether
thecalleeandcallerusethecodec(s)uponwhichtheyhadpreviously
agreed.
3.6.ProtocolRepair
SBCsarealsousedtorepairprotocolmessagesgeneratedbynot
fullystandardcompliantorbadlyimplementedclients.Operatorsmay
wishtosupportprotocolrepair,iftheywanttosupportasmany
clientsaspossible.Itisnoteworthythatthisfunctionaffects
onlythesignalingcomponentofanSBC,andthattheprotocolrepair
functionisnotthesameasprotocolconversion(i.e.,making
translationbetweentwocompletelydifferentprotocols).
39/52
5/5/2015
40/52
5/5/2015
Inmanycases,doingprotocolrepairforSIPheaderfieldscanbe
seenasbeingcompatiblewithSIParchitecturalprinciples,andit
doesnotviolatetheendtoendmodelofSIP.TheSBCrepairing
protocolmessagesbehavesasaproxyserverthatisliberalinwhat
itacceptsandstrictinwhatitsends.
However,protocolrepairmaybreaksecuritymechanismthatdo
cryptographicalcomputationsonSIPheadervalues.Attempting
protocolrepairforSIPmessagebodies(SDP)isincompatiblewith
AuthenticatedIdentityManagement[4]andendtoendsecurity
mechanismssuchasS/MIME.
Asimilarproblemrelatedtoincreasingcomplexity,asexplainedin
Section3.3.2,alsoaffectsprotocolrepairfunction.
3.6.3.Examples
TheSBCcan,forexample,receiveanINVITEmessagefromarelatively
newSIPUAasillustratedinFigure13.
INVITEsip:callee@sbchost.example.com
Via:SIP/2.0/UDPu1.example.com:5060;lr
From:Caller<sip:caller@one.example.com>
To:Callee<sip:callee@two.example.com>
CallID:18293281@u1.example.com
CSeq:1INVITE
Figure13:RequestfromaRelativelyNewClient
IftheSBCdoesprotocolrepair,itcanrewritethe'lr'parameteron
theViaheaderfieldintotheform'lr=true'inordertosupportsome
older,badlyimplementedSIPstacks.Itcouldalsoremoveexcess
whitespacestomaketheSIPmessagemorehumanreadable.
3.7.MediaEncryption
SBCsareusedtoperformmediaencryption/decryptionattheedgeof
thenetwork.Thisisthecasewhenmediaencryption(e.g.,Secure
RealtimeTransportProtocol(SRTP))isusedonlyontheaccess
network(outernetwork)sideandthemediaiscarriedunencryptedin
theinnernetwork.Someoperatorsprovidetheabilitytodolegal
41/52
5/5/2015
42/52
5/5/2015
interceptionwhilestillgivingtheircustomerstheabilityto
encryptmediaintheaccessnetwork.Onepossiblewaytodothisis
toperformmediaencryptionfunction.
Whileperformingamediaencryptionfunction,SBCsneedtobeableto
injecteitherthemselves,orsomeotherentitytothemediapath.It
mustbenotedthatthiskindofbehavioristhesameasaclassical
MITMattack.Duetothis,theSBCshavethesamearchitectural
issuesasexplainedinSection3.2.
3.7.3.Example
Figure14showsanexamplewheretheSBCisperformingmedia
encryptionrelatedfunctions(ACKsomittedforbrevity).
callerSBC#1SBC#2callee
||||
|INVITE+SDP|||
|>|||
|[ModifytheSDP]||
||||
||INVITE+mod.SDP||
||>||
||[ModifytheSDP]|
||||
|||INVITE+mod.SDP|
|||>|
||||
|||200OK+SDP|
|||<|
||[ModifytheSDP]|
||||
||200OK+mod.SDP||
||<||
|[ModifytheSDP]||
||||
|200OK+mod.SDP|||
|<|||
||||
|Encrypted|Plain|Encrypted|
|media[enc./dec.]media[enc./dec.]media|
|<==================>|<>|<==================>|
||||
Figure14:MediaEncryptionExample
43/52
5/5/2015
44/52
5/5/2015
First,theUACsendsanINVITErequest,andthefirstSBCmodifies
thesessiondescriptorinawaythatitinjectsitselftothemedia
path.ThesamehappensinthesecondSBC.Then,theUserAgent
Server(UAS)replieswitha200OKresponseandtheSBCsinject
themselvesinthereturningmediapath.Aftersignaling,themedia
startsflowing,andbothSBCsperformmediaencryptionand
decryption.
4.DerivedRequirementsforFutureSIPStandardizationWork
SomeofthefunctionslistedinthisdocumentaremoreSIPunfriendly
thanothers.Thislistofrequirementsisderivedfromthefunctions
thatbreaktheprinciplesofSIPinonewayoranotherwhenperformed
bySBCsthatdonothavetheusers'consent.Thederived
requirementsare:
Req1:ThereshouldbeaSIPfriendlywaytohidenetworktopology
information.Currently,thisisdonebystrippingand
replacingheaderfields,whichisagainsttheprinciplesof
SIPonbehalfofsomeheaderfields(seeSection3.1).
Req2:ThereshouldbeaSIPfriendlywaytodirectmediatraffic
throughintermediaries.Currently,thisisdonebymodifying
sessiondescriptors,whichisagainsttheprinciplesofSIP
(seeSections3.2,3.4,3.5,and3.7).
Req3:ThereshouldbeaSIPfriendlywaytofixcapability
mismatchesinSIPmessages.Thisrequirementisharderto
fulfilloncomplexmismatchcases,likethe3GPP/SIP[1]
networkmismatch.Currently,thisisdonebymodifyingSIP
messages,whichmayviolateendtoendsecurity(seeSections
3.3and3.6),onbehalfofsomeheaderfields.
Req1andReq3donothaveanexisting,standardizedsolutiontoday.
ThereisongoingworkintheIETFforaddressingReq2,suchasSIP
sessionpolicies[10],TraversalUsingRelaysaroundNAT(TURN)[11],
andInteractiveConnectivityEstablishment(ICE)[12].Nonetheless,
futureworkisneededinordertodevelopsolutionstothese
requirements.
5.SecurityConsiderations
Manyofthefunctionsthisdocumentdescribeshaveimportantsecurity
andprivacyimplications.Onemajorsecurityproblemisthatmany
functionsimplementedbySBCs(e.g.,topologyhidingandmedia
trafficmanagement)modifySIPmessagesandtheirbodieswithoutthe
useragents'consent.Theresultisthattheuseragentsmay
45/52
5/5/2015
46/52
5/5/2015
interprettheactionstakenbyanSBCasaMITMattack.SBCsmodify
SIPmessagesbecauseitallowsthemto,forexample,protectelements
intheinnernetworkfromdirectattacks.
SBCsthatplacethemselves(oranotherentity)onthemediapathcan
beusedtoeavesdroponconversations.Since,often,useragents
cannotdistinguishbetweentheactionsofanattackerandthoseofan
SBC,userscannotknowwhethertheyarebeingeavesdroppedonorif
anSBConthepathisperformingsomeotherfunction.SBCsplace
themselvesonthemediapathbecauseitallowsthemto,forexample,
performlegalinterception.
Onagenerallevel,SBCspreventtheuseofendtoend
authentication.ThisisbecauseSBCsneedtobeabletoperform
actionsthatlooklikeMITMattacks,andinorderforuseragentsto
communicate,theymustallowthosetypeofattacks.Itotherwords,
useragentscannotuseendtoendsecurity.Thisisespecially
harmfulbecauseothernetworkelements,besidesSBCs,arethenable
todosimilarattacks.However,insomecases,useragentscan
establishencryptedmediaconnectionsbetweenoneanother.One
exampleisascenariowhereSBCisusedforenablingmediamonitoring
butnotforinterception.
AnSBCisasinglepointoffailurefromthearchitecturalpointof
view.ThismakesitanattractivetargetforDoSattacks.Thefact
thatsomefunctionsofSBCsrequirethoseSBCstomaintainsession
specificinformationmakesthesituationevenworse.IftheSBC
crashes(orisbroughtdownbyanattacker),ongoingsessions
experienceundeterminedbehavior.
IftheIETFdecidestodevelopstandardmechanismstoaddressthe
requirementspresentedinSection4,thesecurityandprivacyrelated
aspectsofthosemechanismswill,ofcourse,needtobetakeninto
consideration.
6.Acknowledgements
TheadhocmeetingaboutSBCs,heldonNovember9,2004inWashington
DCduringthe61stIETFmeeting,providedvaluableinputtothis
document.TheauthorswouldalsoliketothankSridharRamachandran,
GauravKulshreshtha,andRakenduDevdhar.ReviewersSpencerDawkins
andFrancoisAudetalsodeservespecialthanks.
47/52
5/5/2015
48/52
5/5/2015
7.References
7.1.NormativeReferences
[1]Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,
Peterson,J.,Sparks,R.,Handley,M.,andE.Schooler,"SIP:
SessionInitiationProtocol",RFC3261,June2002.
[2]Peterson,J.,"APrivacyMechanismfortheSessionInitiation
Protocol(SIP)",RFC3323,November2002.
[3]Willis,D.andB.Hoeneisen,"SessionInitiationProtocol(SIP)
ExtensionHeaderFieldforRegisteringNonAdjacentContacts",
RFC3327,December2002.
[4]Peterson,J.andC.Jennings,"EnhancementsforAuthenticated
IdentityManagementintheSessionInitiationProtocol(SIP)",
RFC4474,August2006.
[5]Rosenberg,J.andH.Schulzrinne,"AnOffer/AnswerModelwith
SessionDescriptionProtocol(SDP)",RFC3264,June2002.
7.2.InformativeReferences
[6]3GPP,"IPMultimediaSubsystem(IMS);Stage2",3GPPTS23.228
10.0.0,March2010.
[7]Handley,M.,Jacobson,V.,andC.Perkins,"SDP:Session
DescriptionProtocol",RFC4566,July2006.
[8]Munakata,M.,Schubert,S.,andT.Ohba,"UserAgentDriven
PrivacyMechanismforSIP",RFC5767,April2010.
[9]Eggert,L.andG.Fairhurst,"UnicastUDPUsageGuidelinesfor
ApplicationDesigners",BCP145,RFC5405,November2008.
[10]Hilt,V.,Camarillo,G.,andJ.Rosenberg,"AFrameworkfor
SessionInitiationProtocol(SIP)SessionPolicies",Work
inProgress,February2010.
[11]Mahy,R.,Matthews,P.,andJ.Rosenberg,"TraversalUsing
RelaysaroundNAT(TURN):RelayExtensionstoSessionTraversal
UtilitiesforNAT(STUN)",RFC5766,April2010.
[12]Rosenberg,J.,"InteractiveConnectivityEstablishment(ICE):A
ProtocolforNetworkAddressTranslator(NAT)Traversalfor
Offer/AnswerProtocols",RFC5245,MonthTBD2010.
49/52
5/5/2015
50/52
5/5/2015
Authors'Addresses
JaniHautakorpi(editor)
Ericsson
Hirsalantie11
Jorvas02420
Finland
EMail:Jani.Hautakorpi@ericsson.com
GonzaloCamarillo
Ericsson
Hirsalantie11
Jorvas02420
Finland
EMail:Gonzalo.Camarillo@ericsson.com
RobertF.Penfield
AcmePacket
71ThirdAvenue
Burlington,MA01803
US
EMail:bpenfield@acmepacket.com
AlanHawrylyshen
Skype,Inc.
2055E.HamiltonAve
SanJose,CA95125
US
EMail:alan.ietf@polyphase.ca
MedhaviBhatia
3CLogic
9700GreatSenecaHwy.
Rockville,MD20850
US
EMail:mbhatia@3clogic.com
51/52
5/5/2015
52/52

RFC 5853 - Requirements From Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RFC 5853 - Requirements From Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments PDF

Загружено:

Авторское право:

Доступные форматы

5/5/2015

Вам также может понравиться