An example would be sips:[email protected]. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP ...
[Search][txt|html|pdf|witherrata|bibtex][Tracker][WG][Email][Diff1][Diff2][Nits]
From:draft-ietf-sip-rfc2543bis-09ProposedStandard
Updatedby:3265,3853,4320,4916,5393,5621,IPRdeclarations
5626,5630,5922,5954,6026,6141,Errataexist
6665,6878,7462,7463,8217,8591,
8760,8898,8996
NetworkWorkingGroupJ.Rosenberg
RequestforComments:3261dynamicsoft
Obsoletes:2543H.Schulzrinne
Category:StandardsTrackColumbiaU.
G.Camarillo
Ericsson
A.Johnston
WorldCom
J.Peterson
Neustar
R.Sparks
dynamicsoft
M.Handley
ICIR
E.Schooler
AT&T
June2002
SIP:SessionInitiationProtocol
StatusofthisMemo
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.
CopyrightNotice
Copyright(C)TheInternetSociety(2002).AllRightsReserved.
Abstract
ThisdocumentdescribesSessionInitiationProtocol(SIP),an
application-layercontrol(signaling)protocolforcreating,
modifying,andterminatingsessionswithoneormoreparticipants.
ThesesessionsincludeInternettelephonecalls,multimedia
distribution,andmultimediaconferences.
SIPinvitationsusedtocreatesessionscarrysessiondescriptions
thatallowparticipantstoagreeonasetofcompatiblemediatypes.
SIPmakesuseofelementscalledproxyserverstohelprouterequests
totheuser'scurrentlocation,authenticateandauthorizeusersfor
services,implementprovidercall-routingpolicies,andprovide
featurestousers.SIPalsoprovidesaregistrationfunctionthat
allowsuserstouploadtheircurrentlocationsforusebyproxy
servers.SIPrunsontopofseveraldifferenttransportprotocols.
Rosenberg,et.al.StandardsTrack[Page1]
RFC3261SIP:SessionInitiationProtocolJune2002
TableofContents
1Introduction........................................8
2OverviewofSIPFunctionality.......................9
3Terminology.........................................10
4OverviewofOperation...............................10
5StructureoftheProtocol...........................18
6Definitions.........................................20
7SIPMessages........................................26
7.1Requests............................................27
7.2Responses...........................................28
7.3HeaderFields.......................................29
7.3.1HeaderFieldFormat.................................30
7.3.2HeaderFieldClassification.........................32
7.3.3CompactForm........................................32
7.4Bodies..............................................33
7.4.1MessageBodyType...................................33
7.4.2MessageBodyLength.................................33
7.5FramingSIPMessages................................34
8GeneralUserAgentBehavior.........................34
8.1UACBehavior........................................35
8.1.1GeneratingtheRequest..............................35
8.1.1.1Request-URI.........................................35
8.1.1.2To..................................................36
8.1.1.3From................................................37
8.1.1.4Call-ID.............................................37
8.1.1.5CSeq................................................38
8.1.1.6Max-Forwards........................................38
8.1.1.7Via.................................................39
8.1.1.8Contact.............................................40
8.1.1.9SupportedandRequire...............................40
8.1.1.10AdditionalMessageComponents.......................41
8.1.2SendingtheRequest.................................41
8.1.3ProcessingResponses................................42
8.1.3.1TransactionLayerErrors............................42
8.1.3.2UnrecognizedResponses..............................42
8.1.3.3Vias................................................43
8.1.3.4Processing3xxResponses............................43
8.1.3.5Processing4xxResponses............................45
8.2UASBehavior........................................46
8.2.1MethodInspection...................................46
8.2.2HeaderInspection...................................46
8.2.2.1ToandRequest-URI..................................46
8.2.2.2MergedRequests.....................................47
8.2.2.3Require.............................................47
8.2.3ContentProcessing..................................48
8.2.4ApplyingExtensions.................................49
8.2.5ProcessingtheRequest..............................49
Rosenberg,et.al.StandardsTrack[Page2]
RFC3261SIP:SessionInitiationProtocolJune2002
8.2.6GeneratingtheResponse.............................49
8.2.6.1SendingaProvisionalResponse......................49
8.2.6.2HeadersandTags....................................50
8.2.7StatelessUASBehavior..............................50
8.3RedirectServers....................................51
9CancelingaRequest.................................53
9.1ClientBehavior.....................................53
9.2ServerBehavior.....................................55
10Registrations.......................................56
10.1Overview............................................56
10.2ConstructingtheREGISTERRequest...................57
10.2.1AddingBindings.....................................59
10.2.1.1SettingtheExpirationIntervalofContactAddresses60
10.2.1.2PreferencesamongContactAddresses.................61
10.2.2RemovingBindings...................................61
10.2.3FetchingBindings...................................61
10.2.4RefreshingBindings.................................61
10.2.5SettingtheInternalClock..........................62
10.2.6DiscoveringaRegistrar.............................62
10.2.7TransmittingaRequest..............................62
10.2.8ErrorResponses.....................................63
10.3ProcessingREGISTERRequests........................63
11QueryingforCapabilities...........................66
11.1ConstructionofOPTIONSRequest.....................67
11.2ProcessingofOPTIONSRequest.......................68
12Dialogs.............................................69
12.1CreationofaDialog................................70
12.1.1UASbehavior........................................70
12.1.2UACBehavior........................................71
12.2RequestswithinaDialog............................72
12.2.1UACBehavior........................................73
12.2.1.1GeneratingtheRequest..............................73
12.2.1.2ProcessingtheResponses............................75
12.2.2UASBehavior........................................76
12.3TerminationofaDialog.............................77
13InitiatingaSession................................77
13.1Overview............................................77
13.2UACProcessing......................................78
13.2.1CreatingtheInitialINVITE.........................78
13.2.2ProcessingINVITEResponses.........................81
13.2.2.11xxResponses.......................................81
13.2.2.23xxResponses.......................................81
13.2.2.34xx,5xxand6xxResponses..........................81
13.2.2.42xxResponses.......................................82
13.3UASProcessing......................................83
13.3.1ProcessingoftheINVITE............................83
13.3.1.1Progress............................................84
13.3.1.2TheINVITEisRedirected............................84
Rosenberg,et.al.StandardsTrack[Page3]
RFC3261SIP:SessionInitiationProtocolJune2002
13.3.1.3TheINVITEisRejected..............................85
13.3.1.4TheINVITEisAccepted..............................85
14ModifyinganExistingSession.......................86
14.1UACBehavior........................................86
14.2UASBehavior........................................88
15TerminatingaSession...............................89
15.1TerminatingaSessionwithaBYERequest............90
15.1.1UACBehavior........................................90
15.1.2UASBehavior........................................91
16ProxyBehavior......................................91
16.1Overview............................................91
16.2StatefulProxy......................................92
16.3RequestValidation..................................94
16.4RouteInformationPreprocessing.....................96
16.5DeterminingRequestTargets.........................97
16.6RequestForwarding..................................99
16.7ResponseProcessing.................................107
16.8ProcessingTimerC..................................114
16.9HandlingTransportErrors...........................115
16.10CANCELProcessing...................................115
16.11StatelessProxy.....................................116
16.12SummaryofProxyRouteProcessing...................118
16.12.1Examples............................................118
16.12.1.1BasicSIPTrapezoid.................................118
16.12.1.2TraversingaStrict-RoutingProxy...................120
16.12.1.3RewritingRecord-RouteHeaderFieldValues..........121
17Transactions........................................122
17.1ClientTransaction..................................124
17.1.1INVITEClientTransaction...........................125
17.1.1.1OverviewofINVITETransaction......................125
17.1.1.2FormalDescription..................................125
17.1.1.3ConstructionoftheACKRequest.....................129
17.1.2Non-INVITEClientTransaction.......................130
17.1.2.1Overviewofthenon-INVITETransaction..............130
17.1.2.2FormalDescription..................................131
17.1.3MatchingResponsestoClientTransactions...........132
17.1.4HandlingTransportErrors...........................133
17.2ServerTransaction..................................134
17.2.1INVITEServerTransaction...........................134
17.2.2Non-INVITEServerTransaction.......................137
17.2.3MatchingRequeststoServerTransactions............138
17.2.4HandlingTransportErrors...........................141
18Transport...........................................141
18.1Clients.............................................142
18.1.1SendingRequests....................................142
18.1.2ReceivingResponses.................................144
18.2Servers.............................................145
18.2.1ReceivingRequests..................................145
Rosenberg,et.al.StandardsTrack[Page4]
RFC3261SIP:SessionInitiationProtocolJune2002
18.2.2SendingResponses...................................146
18.3Framing.............................................147
18.4ErrorHandling......................................147
19CommonMessageComponents...........................147
19.1SIPandSIPSUniformResourceIndicators............148
19.1.1SIPandSIPSURIComponents.........................148
19.1.2CharacterEscapingRequirements.....................152
19.1.3ExampleSIPandSIPSURIs...........................153
19.1.4URIComparison......................................153
19.1.5FormingRequestsfromaURI.........................156
19.1.6RelatingSIPURIsandtelURLs......................157
19.2OptionTags.........................................158
19.3Tags................................................159
20HeaderFields.......................................159
20.1Accept..............................................161
20.2Accept-Encoding.....................................163
20.3Accept-Language.....................................164
20.4Alert-Info..........................................164
20.5Allow...............................................165
20.6Authentication-Info.................................165
20.7Authorization.......................................165
20.8Call-ID.............................................166
20.9Call-Info...........................................166
20.10Contact.............................................167
20.11Content-Disposition.................................168
20.12Content-Encoding....................................169
20.13Content-Language....................................169
20.14Content-Length......................................169
20.15Content-Type........................................170
20.16CSeq................................................170
20.17Date................................................170
20.18Error-Info..........................................171
20.19Expires.............................................171
20.20From................................................172
20.21In-Reply-To.........................................172
20.22Max-Forwards........................................173
20.23Min-Expires.........................................173
20.24MIME-Version........................................173
20.25Organization........................................174
20.26Priority............................................174
20.27Proxy-Authenticate..................................174
20.28Proxy-Authorization.................................175
20.29Proxy-Require.......................................175
20.30Record-Route........................................175
20.31Reply-To............................................176
20.32Require.............................................176
20.33Retry-After.........................................176
20.34Route...............................................177
Rosenberg,et.al.StandardsTrack[Page5]
RFC3261SIP:SessionInitiationProtocolJune2002
20.35Server..............................................177
20.36Subject.............................................177
20.37Supported...........................................178
20.38Timestamp...........................................178
20.39To..................................................178
20.40Unsupported.........................................179
20.41User-Agent..........................................179
20.42Via.................................................179
20.43Warning.............................................180
20.44WWW-Authenticate....................................182
21ResponseCodes......................................182
21.1Provisional1xx.....................................182
21.1.1100Trying..........................................183
21.1.2180Ringing.........................................183
21.1.3181CallIsBeingForwarded.........................183
21.1.4182Queued..........................................183
21.1.5183SessionProgress................................183
21.2Successful2xx......................................183
21.2.1200OK..............................................183
21.3Redirection3xx.....................................184
21.3.1300MultipleChoices................................184
21.3.2301MovedPermanently...............................184
21.3.3302MovedTemporarily...............................184
21.3.4305UseProxy.......................................185
21.3.5380AlternativeService.............................185
21.4RequestFailure4xx.................................185
21.4.1400BadRequest.....................................185
21.4.2401Unauthorized....................................185
21.4.3402PaymentRequired................................186
21.4.4403Forbidden.......................................186
21.4.5404NotFound.......................................186
21.4.6405MethodNotAllowed..............................186
21.4.7406NotAcceptable..................................186
21.4.8407ProxyAuthenticationRequired...................186
21.4.9408RequestTimeout.................................186
21.4.10410Gone............................................187
21.4.11413RequestEntityTooLarge........................187
21.4.12414Request-URITooLong............................187
21.4.13415UnsupportedMediaType..........................187
21.4.14416UnsupportedURIScheme..........................187
21.4.15420BadExtension...................................187
21.4.16421ExtensionRequired..............................188
21.4.17423IntervalTooBrief..............................188
21.4.18480TemporarilyUnavailable.........................188
21.4.19481Call/TransactionDoesNotExist.................188
21.4.20482LoopDetected...................................188
21.4.21483TooManyHops...................................189
21.4.22484AddressIncomplete..............................189
Rosenberg,et.al.StandardsTrack[Page6]
RFC3261SIP:SessionInitiationProtocolJune2002
21.4.23485Ambiguous.......................................189
21.4.24486BusyHere.......................................189
21.4.25487RequestTerminated..............................190
21.4.26488NotAcceptableHere.............................190
21.4.27491RequestPending.................................190
21.4.28493Undecipherable..................................190
21.5ServerFailure5xx..................................190
21.5.1500ServerInternalError...........................190
21.5.2501NotImplemented.................................191
21.5.3502BadGateway.....................................191
21.5.4503ServiceUnavailable.............................191
21.5.5504ServerTime-out.................................191
21.5.6505VersionNotSupported...........................192
21.5.7513MessageTooLarge...............................192
21.6GlobalFailures6xx.................................192
21.6.1600BusyEverywhere.................................192
21.6.2603Decline.........................................192
21.6.3604DoesNotExistAnywhere.........................192
21.6.4606NotAcceptable..................................192
22UsageofHTTPAuthentication........................193
22.1Framework...........................................193
22.2User-to-UserAuthentication.........................195
22.3Proxy-to-UserAuthentication........................197
22.4TheDigestAuthenticationScheme....................199
23S/MIME..............................................201
23.1S/MIMECertificates.................................201
23.2S/MIMEKeyExchange.................................202
23.3SecuringMIMEbodies................................205
23.4SIPHeaderPrivacyandIntegrityusingS/MIME:
TunnelingSIP.......................................207
23.4.1IntegrityandConfidentialityPropertiesofSIP
Headers.............................................207
23.4.1.1Integrity...........................................207
23.4.1.2Confidentiality.....................................208
23.4.2TunnelingIntegrityandAuthentication..............209
23.4.3TunnelingEncryption................................211
24Examples............................................213
24.1Registration........................................213
24.2SessionSetup.......................................214
25AugmentedBNFfortheSIPProtocol..................219
25.1BasicRules.........................................219
26SecurityConsiderations:ThreatModelandSecurity
UsageRecommendations...............................232
26.1AttacksandThreatModels...........................233
26.1.1RegistrationHijacking..............................233
26.1.2ImpersonatingaServer..............................234
26.1.3TamperingwithMessageBodies.......................235
26.1.4TearingDownSessions...............................235
Rosenberg,et.al.StandardsTrack[Page7]
RFC3261SIP:SessionInitiationProtocolJune2002
26.1.5DenialofServiceandAmplification.................236
26.2SecurityMechanisms.................................237
26.2.1TransportandNetworkLayerSecurity................238
26.2.2SIPSURIScheme.....................................239
26.2.3HTTPAuthentication.................................240
26.2.4S/MIME..............................................240
26.3ImplementingSecurityMechanisms....................241
26.3.1RequirementsforImplementersofSIP................241
26.3.2SecuritySolutions..................................242
26.3.2.1Registration........................................242
26.3.2.2InterdomainRequests................................243
26.3.2.3Peer-to-PeerRequests...............................245
26.3.2.4DoSProtection......................................246
26.4Limitations.........................................247
26.4.1HTTPDigest.........................................247
26.4.2S/MIME..............................................248
26.4.3TLS.................................................249
26.4.4SIPSURIs...........................................249
26.5Privacy.............................................251
27IANAConsiderations.................................252
27.1OptionTags.........................................252
27.2Warn-Codes..........................................252
27.3HeaderFieldNames..................................253
27.4MethodandResponseCodes...........................253
27.5The"message/sip"MIMEtype........................254
27.6NewContent-DispositionParameterRegistrations.....255
28ChangesFromRFC2543...............................255
28.1MajorFunctionalChanges............................255
28.2MinorFunctionalChanges............................260
29NormativeReferences................................261
30InformativeReferences..............................262
ATableofTimerValues...............................265
Acknowledgments................................................266
Authors'Addresses.............................................267
FullCopyrightStatement.......................................269
1Introduction
TherearemanyapplicationsoftheInternetthatrequirethecreation
andmanagementofasession,whereasessionisconsideredan
exchangeofdatabetweenanassociationofparticipants.The
implementationoftheseapplicationsiscomplicatedbythepractices
ofparticipants:usersmaymovebetweenendpoints,theymaybe
addressablebymultiplenames,andtheymaycommunicateinseveral
differentmedia-sometimessimultaneously.Numerousprotocolshave
beenauthoredthatcarryvariousformsofreal-timemultimedia
sessiondatasuchasvoice,video,ortextmessages.TheSession
InitiationProtocol(SIP)worksinconcertwiththeseprotocolsby
Rosenberg,et.al.StandardsTrack[Page8]
RFC3261SIP:SessionInitiationProtocolJune2002
enablingInternetendpoints(calleduseragents)todiscoverone
anotherandtoagreeonacharacterizationofasessiontheywould
liketoshare.Forlocatingprospectivesessionparticipants,and
forotherfunctions,SIPenablesthecreationofaninfrastructureof
networkhosts(calledproxyservers)towhichuseragentscansend
registrations,invitationstosessions,andotherrequests.SIPis
anagile,general-purposetoolforcreating,modifying,and
terminatingsessionsthatworksindependentlyofunderlyingtransport
protocolsandwithoutdependencyonthetypeofsessionthatisbeing
established.
2OverviewofSIPFunctionality
SIPisanapplication-layercontrolprotocolthatcanestablish,
modify,andterminatemultimediasessions(conferences)suchas
Internettelephonycalls.SIPcanalsoinviteparticipantsto
alreadyexistingsessions,suchasmulticastconferences.Mediacan
beaddedto(andremovedfrom)anexistingsession.SIP
transparentlysupportsnamemappingandredirectionservices,which
supportspersonalmobility[27]-userscanmaintainasingle
externallyvisibleidentifierregardlessoftheirnetworklocation.
SIPsupportsfivefacetsofestablishingandterminatingmultimedia
communications:
Userlocation:determinationoftheendsystemtobeusedfor
communication;
Useravailability:determinationofthewillingnessofthecalled
partytoengageincommunications;
Usercapabilities:determinationofthemediaandmediaparameters
tobeused;
Sessionsetup:"ringing",establishmentofsessionparametersat
bothcalledandcallingparty;
Sessionmanagement:includingtransferandterminationof
sessions,modifyingsessionparameters,andinvoking
services.
SIPisnotaverticallyintegratedcommunicationssystem.SIPis
ratheracomponentthatcanbeusedwithotherIETFprotocolsto
buildacompletemultimediaarchitecture.Typically,these
architectureswillincludeprotocolssuchastheReal-timeTransport
Protocol(RTP)(RFC1889[28])fortransportingreal-timedataand
providingQoSfeedback,theReal-Timestreamingprotocol(RTSP)(RFC
2326[29])forcontrollingdeliveryofstreamingmedia,theMedia
Rosenberg,et.al.StandardsTrack[Page9]
RFC3261SIP:SessionInitiationProtocolJune2002
GatewayControlProtocol(MEGACO)(RFC3015[30])forcontrolling
gatewaystothePublicSwitchedTelephoneNetwork(PSTN),andthe
SessionDescriptionProtocol(SDP)(RFC2327[1])fordescribing
multimediasessions.Therefore,SIPshouldbeusedinconjunction
withotherprotocolsinordertoprovidecompleteservicestothe
users.However,thebasicfunctionalityandoperationofSIPdoes
notdependonanyoftheseprotocols.
SIPdoesnotprovideservices.Rather,SIPprovidesprimitivesthat
canbeusedtoimplementdifferentservices.Forexample,SIPcan
locateauseranddeliveranopaqueobjecttohiscurrentlocation.
Ifthisprimitiveisusedtodeliverasessiondescriptionwrittenin
SDP,forinstance,theendpointscanagreeontheparametersofa
session.Ifthesameprimitiveisusedtodeliveraphotoofthe
calleraswellasthesessiondescription,a"callerID"servicecan
beeasilyimplemented.Asthisexampleshows,asingleprimitiveis
typicallyusedtoprovideseveraldifferentservices.
SIPdoesnotofferconferencecontrolservicessuchasfloorcontrol
orvotinganddoesnotprescribehowaconferenceistobemanaged.
SIPcanbeusedtoinitiateasessionthatusessomeotherconference
controlprotocol.SinceSIPmessagesandthesessionstheyestablish
canpassthroughentirelydifferentnetworks,SIPcannot,anddoes
not,provideanykindofnetworkresourcereservationcapabilities.
Thenatureoftheservicesprovidedmakesecurityparticularly
important.Tothatend,SIPprovidesasuiteofsecurityservices,
whichincludedenial-of-serviceprevention,authentication(bothuser
touserandproxytouser),integrityprotection,andencryptionand
privacyservices.
SIPworkswithbothIPv4andIPv6.
3Terminology
Inthisdocument,thekeywords"MUST","MUSTNOT","REQUIRED",
"SHALL","SHALLNOT","SHOULD","SHOULDNOT","RECOMMENDED","NOT
RECOMMENDED","MAY",and"OPTIONAL"aretobeinterpretedas
describedinBCP14,RFC2119[2]andindicaterequirementlevelsfor
compliantSIPimplementations.
4OverviewofOperation
ThissectionintroducesthebasicoperationsofSIPusingsimple
examples.Thissectionistutorialinnatureanddoesnotcontain
anynormativestatements.
Rosenberg,et.al.StandardsTrack[Page10]
RFC3261SIP:SessionInitiationProtocolJune2002
ThefirstexampleshowsthebasicfunctionsofSIP:locationofan
endpoint,signalofadesiretocommunicate,negotiationofsession
parameterstoestablishthesession,andteardownofthesessiononce
established.
Figure1showsatypicalexampleofaSIPmessageexchangebetween
twousers,AliceandBob.(Eachmessageislabeledwiththeletter
"F"andanumberforreferencebythetext.)Inthisexample,Alice
usesaSIPapplicationonherPC(referredtoasasoftphone)tocall
BobonhisSIPphoneovertheInternet.AlsoshownaretwoSIPproxy
serversthatactonbehalfofAliceandBobtofacilitatethesession
establishment.Thistypicalarrangementisoftenreferredtoasthe
"SIPtrapezoid"asshownbythegeometricshapeofthedottedlines
inFigure1.
Alice"calls"BobusinghisSIPidentity,atypeofUniformResource
Identifier(URI)calledaSIPURI.SIPURIsaredefinedinSection
19.1.Ithasasimilarformtoanemailaddress,typically
containingausernameandahostname.Inthiscase,itis
sip:[email protected],wherebiloxi.comisthedomainofBob'sSIP
serviceprovider.AlicehasaSIPURIofsip:[email protected].
AlicemighthavetypedinBob'sURIorperhapsclickedonahyperlink
oranentryinanaddressbook.SIPalsoprovidesasecureURI,
calledaSIPSURI.Anexamplewouldbesips:[email protected]
madetoaSIPSURIguaranteesthatsecure,encryptedtransport
(namelyTLS)isusedtocarryallSIPmessagesfromthecallertothe
domainofthecallee.Fromthere,therequestissentsecurelyto
thecallee,butwithsecuritymechanismsthatdependonthepolicyof
thedomainofthecallee.
SIPisbasedonanHTTP-likerequest/responsetransactionmodel.
Eachtransactionconsistsofarequestthatinvokesaparticular
method,orfunction,ontheserverandatleastoneresponse.In
thisexample,thetransactionbeginswithAlice'ssoftphonesending
anINVITErequestaddressedtoBob'sSIPURI.INVITEisanexample
ofaSIPmethodthatspecifiestheactionthattherequestor(Alice)
wantstheserver(Bob)totake.TheINVITErequestcontainsanumber
ofheaderfields.Headerfieldsarenamedattributesthatprovide
additionalinformationaboutamessage.Theonespresentinan
INVITEincludeauniqueidentifierforthecall,thedestination
address,Alice'saddress,andinformationaboutthetypeofsession
thatAlicewishestoestablishwithBob.TheINVITE(messageF1in
Figure1)mightlooklikethis:
Rosenberg,et.al.StandardsTrack[Page11]
RFC3261SIP:SessionInitiationProtocolJune2002
atlanta.com...biloxi.com
.proxyproxy.
..
Alice's....................Bob's
softphoneSIPPhone
||||
|INVITEF1|||
|--------------->|INVITEF2||
|100TryingF3|--------------->|INVITEF4|
||
|||
|MediaSession|
|<================================================>|
|BYEF13|
||
||
Figure1:SIPsessionsetupexamplewithSIPtrapezoid
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards:70
To:Bob
From:Alice;tag=1928301774
Call-ID:[email protected]
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:142
(Alice'sSDPnotshown)
Thefirstlineofthetext-encodedmessagecontainsthemethodname
(INVITE).Thelinesthatfollowarealistofheaderfields.This
examplecontainsaminimumrequiredset.Theheaderfieldsare
brieflydescribedbelow:
Rosenberg,et.al.StandardsTrack[Page12]
RFC3261SIP:SessionInitiationProtocolJune2002
Viacontainstheaddress(pc33.atlanta.com)atwhichAliceis
expectingtoreceiveresponsestothisrequest.Italsocontainsa
branchparameterthatidentifiesthistransaction.
Tocontainsadisplayname(Bob)andaSIPorSIPSURI
(sip:[email protected])towardswhichtherequestwasoriginally
directed.DisplaynamesaredescribedinRFC2822[3].
Fromalsocontainsadisplayname(Alice)andaSIPorSIPSURI
(sip:[email protected])thatindicatetheoriginatoroftherequest.
Thisheaderfieldalsohasatagparametercontainingarandomstring
(1928301774)thatwasaddedtotheURIbythesoftphone.Itisused
foridentificationpurposes.
Call-IDcontainsagloballyuniqueidentifierforthiscall,
generatedbythecombinationofarandomstringandthesoftphone's
hostnameorIPaddress.ThecombinationoftheTotag,Fromtag,
andCall-IDcompletelydefinesapeer-to-peerSIPrelationship
betweenAliceandBobandisreferredtoasadialog.
CSeqorCommandSequencecontainsanintegerandamethodname.The
CSeqnumberisincrementedforeachnewrequestwithinadialogand
isatraditionalsequencenumber.
ContactcontainsaSIPorSIPSURIthatrepresentsadirectrouteto
contactAlice,usuallycomposedofausernameatafullyqualified
domainname(FQDN).WhileanFQDNispreferred,manyendsystemsdo
nothaveregistereddomainnames,soIPaddressesarepermitted.
WhiletheViaheaderfieldtellsotherelementswheretosendthe
response,theContactheaderfieldtellsotherelementswheretosend
futurerequests.
Max-Forwardsservestolimitthenumberofhopsarequestcanmakeon
thewaytoitsdestination.Itconsistsofanintegerthatis
decrementedbyoneateachhop.
Content-Typecontainsadescriptionofthemessagebody(notshown).
Content-Lengthcontainsanoctet(byte)countofthemessagebody.
ThecompletesetofSIPheaderfieldsisdefinedinSection20.
Thedetailsofthesession,suchasthetypeofmedia,codec,or
samplingrate,arenotdescribedusingSIP.Rather,thebodyofa
SIPmessagecontainsadescriptionofthesession,encodedinsome
otherprotocolformat.OnesuchformatistheSessionDescription
Protocol(SDP)(RFC2327[1]).ThisSDPmessage(notshowninthe
Rosenberg,et.al.StandardsTrack[Page13]
RFC3261SIP:SessionInitiationProtocolJune2002
example)iscarriedbytheSIPmessageinawaythatisanalogousto
adocumentattachmentbeingcarriedbyanemailmessage,oraweb
pagebeingcarriedinanHTTPmessage.
SincethesoftphonedoesnotknowthelocationofBobortheSIP
serverinthebiloxi.comdomain,thesoftphonesendstheINVITEto
theSIPserverthatservesAlice'sdomain,atlanta.com.Theaddress
oftheatlanta.comSIPservercouldhavebeenconfiguredinAlice's
softphone,oritcouldhavebeendiscoveredbyDHCP,forexample.
Theatlanta.comSIPserverisatypeofSIPserverknownasaproxy
server.AproxyserverreceivesSIPrequestsandforwardsthemon
behalfoftherequestor.Inthisexample,theproxyserverreceives
theINVITErequestandsendsa100(Trying)responsebacktoAlice's
softphone.The100(Trying)responseindicatesthattheINVITEhas
beenreceivedandthattheproxyisworkingonherbehalftoroute
theINVITEtothedestination.ResponsesinSIPuseathree-digit
codefollowedbyadescriptivephrase.Thisresponsecontainsthe
sameTo,From,Call-ID,CSeqandbranchparameterintheViaasthe
INVITE,whichallowsAlice'ssoftphonetocorrelatethisresponseto
thesentINVITE.Theatlanta.comproxyserverlocatestheproxy
serveratbiloxi.com,possiblybyperformingaparticulartypeofDNS
(DomainNameService)lookuptofindtheSIPserverthatservesthe
biloxi.comdomain.Thisisdescribedin[4].Asaresult,it
obtainstheIPaddressofthebiloxi.comproxyserverandforwards,
orproxies,theINVITErequestthere.Beforeforwardingtherequest,
theatlanta.comproxyserveraddsanadditionalViaheaderfield
valuethatcontainsitsownaddress(theINVITEalreadycontains
Alice'saddressinthefirstVia).Thebiloxi.comproxyserver
receivestheINVITEandrespondswitha100(Trying)responsebackto
theatlanta.comproxyservertoindicatethatithasreceivedthe
INVITEandisprocessingtherequest.Theproxyserverconsultsa
database,genericallycalledalocationservice,thatcontainsthe
currentIPaddressofBob.(Weshallseeinthenextsectionhow
thisdatabasecanbepopulated.)Thebiloxi.comproxyserveradds
anotherViaheaderfieldvaluewithitsownaddresstotheINVITEand
proxiesittoBob'sSIPphone.
Bob'sSIPphonereceivestheINVITEandalertsBobtotheincoming
callfromAlicesothatBobcandecidewhethertoanswerthecall,
thatis,Bob'sphonerings.Bob'sSIPphoneindicatesthisina180
(Ringing)response,whichisroutedbackthroughthetwoproxiesin
thereversedirection.EachproxyusestheViaheaderfieldto
determinewheretosendtheresponseandremovesitsownaddressfrom
thetop.Asaresult,althoughDNSandlocationservicelookupswere
requiredtoroutetheinitialINVITE,the180(Ringing)responsecan
bereturnedtothecallerwithoutlookupsorwithoutstatebeing
Rosenberg,et.al.StandardsTrack[Page14]
RFC3261SIP:SessionInitiationProtocolJune2002
maintainedintheproxies.Thisalsohasthedesirablepropertythat
eachproxythatseestheINVITEwillalsoseeallresponsestothe
INVITE.
WhenAlice'ssoftphonereceivesthe180(Ringing)response,itpasses
thisinformationtoAlice,perhapsusinganaudioringbacktoneorby
displayingamessageonAlice'sscreen.
Inthisexample,Bobdecidestoanswerthecall.Whenhepicksup
thehandset,hisSIPphonesendsa200(OK)responsetoindicatethat
thecallhasbeenanswered.The200(OK)containsamessagebody
withtheSDPmediadescriptionofthetypeofsessionthatBobis
willingtoestablishwithAlice.Asaresult,thereisatwo-phase
exchangeofSDPmessages:AlicesentonetoBob,andBobsentone
backtoAlice.Thistwo-phaseexchangeprovidesbasicnegotiation
capabilitiesandisbasedonasimpleoffer/answermodelofSDP
exchange.IfBobdidnotwishtoanswerthecallorwasbusyon
anothercall,anerrorresponsewouldhavebeensentinsteadofthe
200(OK),whichwouldhaveresultedinnomediasessionbeing
established.ThecompletelistofSIPresponsecodesisinSection
21.The200(OK)(messageF9inFigure1)mightlooklikethisas
Bobsendsitout:
SIP/2.0200OK
Via:SIP/2.0/UDPserver10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com
;branch=z9hG4bK776asdhds;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:[email protected]
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:131
(Bob'sSDPnotshown)
Thefirstlineoftheresponsecontainstheresponsecode(200)and
thereasonphrase(OK).Theremaininglinescontainheaderfields.
TheVia,To,From,Call-ID,andCSeqheaderfieldsarecopiedfrom
theINVITErequest.(TherearethreeViaheaderfieldvalues-one
addedbyAlice'sSIPphone,oneaddedbytheatlanta.comproxy,and
oneaddedbythebiloxi.comproxy.)Bob'sSIPphonehasaddedatag
parametertotheToheaderfield.Thistagwillbeincorporatedby
bothendpointsintothedialogandwillbeincludedinallfuture
Rosenberg,et.al.StandardsTrack[Page15]
RFC3261SIP:SessionInitiationProtocolJune2002
requestsandresponsesinthiscall.TheContactheaderfield
containsaURIatwhichBobcanbedirectlyreachedathisSIPphone.
TheContent-TypeandContent-Lengthrefertothemessagebody(not
shown)thatcontainsBob'sSDPmediainformation.
InadditiontoDNSandlocationservicelookupsshowninthis
example,proxyserverscanmakeflexible"routingdecisions"to
decidewheretosendarequest.Forexample,ifBob'sSIPphone
returneda486(BusyHere)response,thebiloxi.comproxyserver
couldproxytheINVITEtoBob'svoicemailserver.Aproxyservercan
alsosendanINVITEtoanumberoflocationsatthesametime.This
typeofparallelsearchisknownasforking.
Inthiscase,the200(OK)isroutedbackthroughthetwoproxiesand
isreceivedbyAlice'ssoftphone,whichthenstopstheringbacktone
andindicatesthatthecallhasbeenanswered.Finally,Alice's
softphonesendsanacknowledgementmessage,ACK,toBob'sSIPphone
toconfirmthereceptionofthefinalresponse(200(OK)).Inthis
example,theACKissentdirectlyfromAlice'ssoftphonetoBob'sSIP
phone,bypassingthetwoproxies.Thisoccursbecausetheendpoints
havelearnedeachother'saddressfromtheContactheaderfields
throughtheINVITE/200(OK)exchange,whichwasnotknownwhenthe
initialINVITEwassent.Thelookupsperformedbythetwoproxies
arenolongerneeded,sotheproxiesdropoutofthecallflow.This
completestheINVITE/200/ACKthree-wayhandshakeusedtoestablish
SIPsessions.FulldetailsonsessionsetupareinSection13.
AliceandBob'smediasessionhasnowbegun,andtheysendmedia
packetsusingtheformattowhichtheyagreedintheexchangeofSDP.
Ingeneral,theend-to-endmediapacketstakeadifferentpathfrom
theSIPsignalingmessages.
Duringthesession,eitherAliceorBobmaydecidetochangethe
characteristicsofthemediasession.Thisisaccomplishedby
sendingare-INVITEcontaininganewmediadescription.Thisre-
INVITEreferencestheexistingdialogsothattheotherpartyknows
thatitistomodifyanexistingsessioninsteadofestablishinga
newsession.Theotherpartysendsa200(OK)toacceptthechange.
Therequestorrespondstothe200(OK)withanACK.Iftheother
partydoesnotacceptthechange,hesendsanerrorresponsesuchas
488(NotAcceptableHere),whichalsoreceivesanACK.However,the
failureofthere-INVITEdoesnotcausetheexistingcalltofail-
thesessioncontinuesusingthepreviouslynegotiated
characteristics.FulldetailsonsessionmodificationareinSection
14.
Rosenberg,et.al.StandardsTrack[Page16]
RFC3261SIP:SessionInitiationProtocolJune2002
Attheendofthecall,Bobdisconnects(hangsup)firstand
generatesaBYEmessage.ThisBYEisrouteddirectlytoAlice's
softphone,againbypassingtheproxies.Aliceconfirmsreceiptof
theBYEwitha200(OK)response,whichterminatesthesessionand
theBYEtransaction.NoACKissent-anACKisonlysentin
responsetoaresponsetoanINVITErequest.Thereasonsforthis
specialhandlingforINVITEwillbediscussedlater,butrelateto
thereliabilitymechanismsinSIP,thelengthoftimeitcantakefor
aringingphonetobeanswered,andforking.Forthisreason,
requesthandlinginSIPisoftenclassifiedaseitherINVITEornon-
INVITE,referringtoallothermethodsbesidesINVITE.Fulldetails
onsessionterminationareinSection15.
Section24.2describesthemessagesshowninFigure1infull.
Insomecases,itmaybeusefulforproxiesintheSIPsignalingpath
toseeallthemessagingbetweentheendpointsforthedurationof
thesession.Forexample,ifthebiloxi.comproxyserverwishedto
remainintheSIPmessagingpathbeyondtheinitialINVITE,itwould
addtotheINVITEarequiredroutingheaderfieldknownasRecord-
RoutethatcontainedaURIresolvingtothehostnameorIPaddressof
theproxy.ThisinformationwouldbereceivedbybothBob'sSIP
phoneand(duetotheRecord-Routeheaderfieldbeingpassedbackin
the200(OK))Alice'ssoftphoneandstoredforthedurationofthe
dialog.Thebiloxi.comproxyserverwouldthenreceiveandproxythe
ACK,BYE,and200(OK)totheBYE.Eachproxycanindependently
decidetoreceivesubsequentmessages,andthosemessageswillpass
throughallproxiesthatelecttoreceiveit.Thiscapabilityis
frequentlyusedforproxiesthatareprovidingmid-callfeatures.
RegistrationisanothercommonoperationinSIP.Registrationisone
waythatthebiloxi.comservercanlearnthecurrentlocationofBob.
Uponinitialization,andatperiodicintervals,Bob'sSIPphonesends
REGISTERmessagestoaserverinthebiloxi.comdomainknownasaSIP
registrar.TheREGISTERmessagesassociateBob'sSIPorSIPSURI
(sip:[email protected])withthemachineintowhichheiscurrently
logged(conveyedasaSIPorSIPSURIintheContactheaderfield).
Theregistrarwritesthisassociation,alsocalledabinding,toa
database,calledthelocationservice,whereitcanbeusedbythe
proxyinthebiloxi.comdomain.Often,aregistrarserverfora
domainisco-locatedwiththeproxyforthatdomain.Itisan
importantconceptthatthedistinctionbetweentypesofSIPservers
islogical,notphysical.
Bobisnotlimitedtoregisteringfromasingledevice.Forexample,
bothhisSIPphoneathomeandtheoneintheofficecouldsend
registrations.Thisinformationisstoredtogetherinthelocation
Rosenberg,et.al.StandardsTrack[Page17]
RFC3261SIP:SessionInitiationProtocolJune2002
serviceandallowsaproxytoperformvarioustypesofsearchesto
locateBob.Similarly,morethanoneusercanberegisteredona
singledeviceatthesametime.
Thelocationserviceisjustanabstractconcept.Itgenerally
containsinformationthatallowsaproxytoinputaURIandreceivea
setofzeroormoreURIsthattelltheproxywheretosendthe
request.Registrationsareonewaytocreatethisinformation,but
nottheonlyway.Arbitrarymappingfunctionscanbeconfiguredat
thediscretionoftheadministrator.
Finally,itisimportanttonotethatinSIP,registrationisused
forroutingincomingSIPrequestsandhasnoroleinauthorizing
outgoingrequests.Authorizationandauthenticationarehandledin
SIPeitheronarequest-by-requestbasiswithachallenge/response
mechanism,orbyusingalowerlayerschemeasdiscussedinSection
26.
ThecompletesetofSIPmessagedetailsforthisregistrationexample
isinSection24.1.
AdditionaloperationsinSIP,suchasqueryingforthecapabilities
ofaSIPserverorclientusingOPTIONS,orcancelingapending
requestusingCANCEL,willbeintroducedinlatersections.
5StructureoftheProtocol
SIPisstructuredasalayeredprotocol,whichmeansthatits
behaviorisdescribedintermsofasetoffairlyindependent
processingstageswithonlyaloosecouplingbetweeneachstage.The
protocolbehaviorisdescribedaslayersforthepurposeof
presentation,allowingthedescriptionoffunctionscommonacross
elementsinasinglesection.Itdoesnotdictateanimplementation
inanyway.Whenwesaythatanelement"contains"alayer,wemean
itiscomplianttothesetofrulesdefinedbythatlayer.
Noteveryelementspecifiedbytheprotocolcontainseverylayer.
Furthermore,theelementsspecifiedbySIParelogicalelements,not
physicalones.Aphysicalrealizationcanchoosetoactasdifferent
logicalelements,perhapsevenonatransaction-by-transactionbasis.
ThelowestlayerofSIPisitssyntaxandencoding.Itsencodingis
specifiedusinganaugmentedBackus-NaurFormgrammar(BNF).The
completeBNFisspecifiedinSection25;anoverviewofaSIP
message'sstructurecanbefoundinSection7.
Rosenberg,et.al.StandardsTrack[Page18]
RFC3261SIP:SessionInitiationProtocolJune2002
Thesecondlayeristhetransportlayer.Itdefineshowaclient
sendsrequestsandreceivesresponsesandhowaserverreceives
requestsandsendsresponsesoverthenetwork.AllSIPelements
containatransportlayer.Thetransportlayerisdescribedin
Section18.
Thethirdlayeristhetransactionlayer.Transactionsarea
fundamentalcomponentofSIP.Atransactionisarequestsentbya
clienttransaction(usingthetransportlayer)toaserver
transaction,alongwithallresponsestothatrequestsentfromthe
servertransactionbacktotheclient.Thetransactionlayerhandles
application-layerretransmissions,matchingofresponsestorequests,
andapplication-layertimeouts.Anytaskthatauseragentclient
(UAC)accomplishestakesplaceusingaseriesoftransactions.
DiscussionoftransactionscanbefoundinSection17.Useragents
containatransactionlayer,asdostatefulproxies.Stateless
proxiesdonotcontainatransactionlayer.Thetransactionlayer
hasaclientcomponent(referredtoasaclienttransaction)anda
servercomponent(referredtoasaservertransaction),eachofwhich
arerepresentedbyafinitestatemachinethatisconstructedto
processaparticularrequest.
Thelayerabovethetransactionlayeriscalledthetransactionuser
(TU).EachoftheSIPentities,exceptthestatelessproxy,isa
transactionuser.WhenaTUwishestosendarequest,itcreatesa
clienttransactioninstanceandpassesittherequestalongwiththe
destinationIPaddress,port,andtransporttowhichtosendthe
request.ATUthatcreatesaclienttransactioncanalsocancelit.
Whenaclientcancelsatransaction,itrequeststhattheserverstop
furtherprocessing,reverttothestatethatexistedbeforethe
transactionwasinitiated,andgenerateaspecificerrorresponseto
thattransaction.ThisisdonewithaCANCELrequest,which
constitutesitsowntransaction,butreferencesthetransactiontobe
cancelled(Section9).
TheSIPelements,thatis,useragentclientsandservers,stateless
andstatefulproxiesandregistrars,containacorethat
distinguishesthemfromeachother.Cores,exceptforthestateless
proxy,aretransactionusers.WhilethebehavioroftheUACandUAS
coresdependsonthemethod,therearesomecommonrulesforall
methods(Section8).ForaUAC,theserulesgoverntheconstruction
ofarequest;foraUAS,theygoverntheprocessingofarequestand
generatingaresponse.Sinceregistrationsplayanimportantrolein
SIP,aUASthathandlesaREGISTERisgiventhespecialname
registrar.Section10describesUACandUAScorebehaviorforthe
REGISTERmethod.Section11describesUACandUAScorebehaviorfor
theOPTIONSmethod,usedfordeterminingthecapabilitiesofaUA.
Rosenberg,et.al.StandardsTrack[Page19]
RFC3261SIP:SessionInitiationProtocolJune2002
Certainotherrequestsaresentwithinadialog.Adialogisa
peer-to-peerSIPrelationshipbetweentwouseragentsthatpersists
forsometime.Thedialogfacilitatessequencingofmessagesand
properroutingofrequestsbetweentheuseragents.TheINVITE
methodistheonlywaydefinedinthisspecificationtoestablisha
dialog.WhenaUACsendsarequestthatiswithinthecontextofa
dialog,itfollowsthecommonUACrulesasdiscussedinSection8but
alsotherulesformid-dialogrequests.Section12discussesdialogs
andpresentstheproceduresfortheirconstructionandmaintenance,
inadditiontoconstructionofrequestswithinadialog.
ThemostimportantmethodinSIPistheINVITEmethod,whichisused
toestablishasessionbetweenparticipants.Asessionisa
collectionofparticipants,andstreamsofmediabetweenthem,for
thepurposesofcommunication.Section13discusseshowsessionsare
initiated,resultinginoneormoreSIPdialogs.Section14
discusseshowcharacteristicsofthatsessionaremodifiedthrough
theuseofanINVITErequestwithinadialog.Finally,section15
discusseshowasessionisterminated.
TheproceduresofSections8,10,11,12,13,14,and15deal
entirelywiththeUAcore(Section9describescancellation,which
appliestobothUAcoreandproxycore).Section16discussesthe
proxyelement,whichfacilitatesroutingofmessagesbetweenuser
agents.
6Definitions
ThefollowingtermshavespecialsignificanceforSIP.
Address-of-Record:Anaddress-of-record(AOR)isaSIPorSIPSURI
thatpointstoadomainwithalocationservicethatcanmap
theURItoanotherURIwheretheusermightbeavailable.
Typically,thelocationserviceispopulatedthrough
registrations.AnAORisfrequentlythoughtofasthe"public
address"oftheuser.
Back-to-BackUserAgent:Aback-to-backuseragent(B2BUA)isa
logicalentitythatreceivesarequestandprocessesitasa
useragentserver(UAS).Inordertodeterminehowtherequest
shouldbeanswered,itactsasauseragentclient(UAC)and
generatesrequests.Unlikeaproxyserver,itmaintainsdialog
stateandmustparticipateinallrequestssentonthedialogs
ithasestablished.SinceitisaconcatenationofaUACand
UAS,noexplicitdefinitionsareneededforitsbehavior.
Rosenberg,et.al.StandardsTrack[Page20]
RFC3261SIP:SessionInitiationProtocolJune2002
Call:Acallisaninformaltermthatreferstosomecommunication
betweenpeers,generallysetupforthepurposesofa
multimediaconversation.
CallLeg:Anothernameforadialog[31];nolongerusedinthis
specification.
CallStateful:Aproxyiscallstatefulifitretainsstatefora
dialogfromtheinitiatingINVITEtotheterminatingBYE
request.Acallstatefulproxyisalwaystransactionstateful,
buttheconverseisnotnecessarilytrue.
Client:AclientisanynetworkelementthatsendsSIPrequests
andreceivesSIPresponses.Clientsmayormaynotinteract
directlywithahumanuser.Useragentclientsandproxiesare
clients.
Conference:Amultimediasession(seebelow)thatcontains
multipleparticipants.
Core:Coredesignatesthefunctionsspecifictoaparticulartype
ofSIPentity,i.e.,specifictoeitherastatefulorstateless
proxy,auseragentorregistrar.Allcores,exceptthosefor
thestatelessproxy,aretransactionusers.
Dialog:Adialogisapeer-to-peerSIPrelationshipbetweentwo
UAsthatpersistsforsometime.Adialogisestablishedby
SIPmessages,suchasa2xxresponsetoanINVITErequest.A
dialogisidentifiedbyacallidentifier,localtag,anda
remotetag.AdialogwasformerlyknownasacallleginRFC
2543.
Downstream:Adirectionofmessageforwardingwithinatransaction
thatreferstothedirectionthatrequestsflowfromtheuser
agentclienttouseragentserver.
FinalResponse:AresponsethatterminatesaSIPtransaction,as
opposedtoaprovisionalresponsethatdoesnot.All2xx,3xx,
4xx,5xxand6xxresponsesarefinal.
Header:AheaderisacomponentofaSIPmessagethatconveys
informationaboutthemessage.Itisstructuredasasequence
ofheaderfields.
HeaderField:AheaderfieldisacomponentoftheSIPmessage
header.Aheaderfieldcanappearasoneormoreheaderfield
rows.Headerfieldrowsconsistofaheaderfieldnameandzero
ormoreheaderfieldvalues.Multipleheaderfieldvaluesona
Rosenberg,et.al.StandardsTrack[Page21]
RFC3261SIP:SessionInitiationProtocolJune2002
givenheaderfieldrowareseparatedbycommas.Someheader
fieldscanonlyhaveasingleheaderfieldvalue,andasa
result,alwaysappearasasingleheaderfieldrow.
HeaderFieldValue:Aheaderfieldvalueisasinglevalue;a
headerfieldconsistsofzeroormoreheaderfieldvalues.
HomeDomain:ThedomainprovidingservicetoaSIPuser.
Typically,thisisthedomainpresentintheURIinthe
address-of-recordofaregistration.
InformationalResponse:Sameasaprovisionalresponse.
Initiator,CallingParty,Caller:Thepartyinitiatingasession
(anddialog)withanINVITErequest.Acallerretainsthis
rolefromthetimeitsendstheinitialINVITEthatestablished
adialoguntiltheterminationofthatdialog.
Invitation:AnINVITErequest.
Invitee,InvitedUser,CalledParty,Callee:Thepartythat
receivesanINVITErequestforthepurposeofestablishinga
newsession.Acalleeretainsthisrolefromthetimeit
receivestheINVITEuntiltheterminationofthedialog
establishedbythatINVITE.
LocationService:AlocationserviceisusedbyaSIPredirector
proxyservertoobtaininformationaboutacallee'spossible
location(s).Itcontainsalistofbindingsofaddress-of-
recordkeystozeroormorecontactaddresses.Thebindings
canbecreatedandremovedinmanyways;thisspecification
definesaREGISTERmethodthatupdatesthebindings.
Loop:Arequestthatarrivesataproxy,isforwarded,andlater
arrivesbackatthesameproxy.Whenitarrivesthesecond
time,itsRequest-URIisidenticaltothefirsttime,andother
headerfieldsthataffectproxyoperationareunchanged,so
thattheproxywouldmakethesameprocessingdecisiononthe
requestitmadethefirsttime.Loopedrequestsareerrors,
andtheproceduresfordetectingthemandhandlingthemare
describedbytheprotocol.
LooseRouting:Aproxyissaidtobelooseroutingifitfollows
theproceduresdefinedinthisspecificationforprocessingof
theRouteheaderfield.Theseproceduresseparatethe
destinationoftherequest(presentintheRequest-URI)from
Rosenberg,et.al.StandardsTrack[Page22]
RFC3261SIP:SessionInitiationProtocolJune2002
thesetofproxiesthatneedtobevisitedalongtheway
(presentintheRouteheaderfield).Aproxycompliantto
thesemechanismsisalsoknownasalooserouter.
Message:DatasentbetweenSIPelementsaspartoftheprotocol.
SIPmessagesareeitherrequestsorresponses.
Method:Themethodistheprimaryfunctionthatarequestismeant
toinvokeonaserver.Themethodiscarriedintherequest
messageitself.ExamplemethodsareINVITEandBYE.
OutboundProxy:Aproxythatreceivesrequestsfromaclient,even
thoughitmaynotbetheserverresolvedbytheRequest-URI.
Typically,aUAismanuallyconfiguredwithanoutboundproxy,
orcanlearnaboutonethroughauto-configurationprotocols.
ParallelSearch:Inaparallelsearch,aproxyissuesseveral
requeststopossibleuserlocationsuponreceivinganincoming
request.Ratherthanissuingonerequestandthenwaitingfor
thefinalresponsebeforeissuingthenextrequestasina
sequentialsearch,aparallelsearchissuesrequestswithout
waitingfortheresultofpreviousrequests.
ProvisionalResponse:Aresponseusedbytheservertoindicate
progress,butthatdoesnotterminateaSIPtransaction.1xx
responsesareprovisional,otherresponsesareconsidered
final.
Proxy,ProxyServer:Anintermediaryentitythatactsasbotha
serverandaclientforthepurposeofmakingrequestson
behalfofotherclients.Aproxyserverprimarilyplaysthe
roleofrouting,whichmeansitsjobistoensurethata
requestissenttoanotherentity"closer"tothetargeted
user.Proxiesarealsousefulforenforcingpolicy(for
example,makingsureauserisallowedtomakeacall).A
proxyinterprets,and,ifnecessary,rewritesspecificpartsof
arequestmessagebeforeforwardingit.
Recursion:Aclientrecursesona3xxresponsewhenitgeneratesa
newrequesttooneormoreoftheURIsintheContactheader
fieldintheresponse.
RedirectServer:Aredirectserverisauseragentserverthat
generates3xxresponsestorequestsitreceives,directingthe
clienttocontactanalternatesetofURIs.
Rosenberg,et.al.StandardsTrack[Page23]
RFC3261SIP:SessionInitiationProtocolJune2002
Registrar:AregistrarisaserverthatacceptsREGISTERrequests
andplacestheinformationitreceivesinthoserequestsinto
thelocationserviceforthedomainithandles.
RegularTransaction:Aregulartransactionisanytransactionwith
amethodotherthanINVITE,ACK,orCANCEL.
Request:ASIPmessagesentfromaclienttoaserver,forthe
purposeofinvokingaparticularoperation.
Response:ASIPmessagesentfromaservertoaclient,for
indicatingthestatusofarequestsentfromtheclienttothe
server.
Ringback:Ringbackisthesignalingtoneproducedbythecalling
party'sapplicationindicatingthatacalledpartyisbeing
alerted(ringing).
RouteSet:AroutesetisacollectionoforderedSIPorSIPSURI
whichrepresentalistofproxiesthatmustbetraversedwhen
sendingaparticularrequest.Aroutesetcanbelearned,
throughheaderslikeRecord-Route,oritcanbeconfigured.
Server:Aserverisanetworkelementthatreceivesrequestsin
ordertoservicethemandsendsbackresponsestothose
requests.Examplesofserversareproxies,useragentservers,
redirectservers,andregistrars.
SequentialSearch:Inasequentialsearch,aproxyserverattempts
eachcontactaddressinsequence,proceedingtothenextone
onlyaftertheprevioushasgeneratedafinalresponse.A2xx
or6xxclassfinalresponsealwaysterminatesasequential
search.
Session:FromtheSDPspecification:"Amultimediasessionisa
setofmultimediasendersandreceiversandthedatastreams
flowingfromsenderstoreceivers.Amultimediaconferenceis
anexampleofamultimediasession."(RFC2327[1])(Asession
asdefinedforSDPcancompriseoneormoreRTPsessions.)As
defined,acalleecanbeinvitedseveraltimes,bydifferent
calls,tothesamesession.IfSDPisused,asessionis
definedbytheconcatenationoftheSDPusername,sessionid,
networktype,addresstype,andaddresselementsintheorigin
field.
SIPTransaction:ASIPtransactionoccursbetweenaclientanda
serverandcomprisesallmessagesfromthefirstrequestsent
fromtheclienttotheserveruptoafinal(non-1xx)response
Rosenberg,et.al.StandardsTrack[Page24]
RFC3261SIP:SessionInitiationProtocolJune2002
sentfromtheservertotheclient.IftherequestisINVITE
andthefinalresponseisanon-2xx,thetransactionalso
includesanACKtotheresponse.TheACKfora2xxresponseto
anINVITErequestisaseparatetransaction.
Spiral:AspiralisaSIPrequestthatisroutedtoaproxy,
forwardedonwards,andarrivesonceagainatthatproxy,but
thistimediffersinawaythatwillresultinadifferent
processingdecisionthantheoriginalrequest.Typically,this
meansthattherequest'sRequest-URIdiffersfromitsprevious
arrival.Aspiralisnotanerrorcondition,unlikealoop.A
typicalcauseforthisiscallforwarding.Ausercalls
[email protected]'s
PC,whichinturn,[email protected]
requestisproxiedbacktotheexample.comproxy.However,
thisisnotaloop.Sincetherequestistargetedata
differentuser,itisconsideredaspiral,andisavalid
condition.
StatefulProxy:Alogicalentitythatmaintainstheclientand
servertransactionstatemachinesdefinedbythisspecification
duringtheprocessingofarequest,alsoknownasatransaction
statefulproxy.Thebehaviorofastatefulproxyisfurther
definedinSection16.A(transaction)statefulproxyisnot
thesameasacallstatefulproxy.
StatelessProxy:Alogicalentitythatdoesnotmaintainthe
clientorservertransactionstatemachinesdefinedinthis
specificationwhenitprocessesrequests.Astatelessproxy
forwardseveryrequestitreceivesdownstreamandevery
responseitreceivesupstream.
StrictRouting:Aproxyissaidtobestrictroutingifitfollows
theRouteprocessingrulesofRFC2543andmanypriorworkin
progressversionsofthisRFC.Thatrulecausedproxiesto
destroythecontentsoftheRequest-URIwhenaRouteheader
fieldwaspresent.Strictroutingbehaviorisnotusedinthis
specification,infavorofalooseroutingbehavior.Proxies
thatperformstrictroutingarealsoknownasstrictrouters.
TargetRefreshRequest:Atargetrefreshrequestsentwithina
dialogisdefinedasarequestthatcanmodifytheremote
targetofthedialog.
TransactionUser(TU):Thelayerofprotocolprocessingthat
residesabovethetransactionlayer.Transactionusersinclude
theUACcore,UAScore,andproxycore.
Rosenberg,et.al.StandardsTrack[Page25]
RFC3261SIP:SessionInitiationProtocolJune2002
Upstream:Adirectionofmessageforwardingwithinatransaction
thatreferstothedirectionthatresponsesflowfromtheuser
agentserverbacktotheuseragentclient.
URL-encoded:AcharacterstringencodedaccordingtoRFC2396,
Section 2.4[5].
UserAgentClient(UAC):Auseragentclientisalogicalentity
thatcreatesanewrequest,andthenusestheclient
transactionstatemachinerytosendit.TheroleofUAClasts
onlyforthedurationofthattransaction.Inotherwords,if
apieceofsoftwareinitiatesarequest,itactsasaUACfor
thedurationofthattransaction.Ifitreceivesarequest
later,itassumestheroleofauseragentserverforthe
processingofthattransaction.
UACCore:ThesetofprocessingfunctionsrequiredofaUACthat
resideabovethetransactionandtransportlayers.
UserAgentServer(UAS):Auseragentserverisalogicalentity
thatgeneratesaresponsetoaSIPrequest.Theresponse
accepts,rejects,orredirectstherequest.Thisrolelasts
onlyforthedurationofthattransaction.Inotherwords,if
apieceofsoftwarerespondstoarequest,itactsasaUASfor
thedurationofthattransaction.Ifitgeneratesarequest
later,itassumestheroleofauseragentclientforthe
processingofthattransaction.
UASCore:ThesetofprocessingfunctionsrequiredataUASthat
residesabovethetransactionandtransportlayers.
UserAgent(UA):Alogicalentitythatcanactasbothauser
agentclientanduseragentserver.
TheroleofUACandUAS,aswellasproxyandredirectservers,are
definedonatransaction-by-transactionbasis.Forexample,theuser
agentinitiatingacallactsasaUACwhensendingtheinitialINVITE
requestandasaUASwhenreceivingaBYErequestfromthecallee.
Similarly,thesamesoftwarecanactasaproxyserverforone
requestandasaredirectserverforthenextrequest.
Proxy,location,andregistrarserversdefinedabovearelogical
entities;implementationsMAYcombinethemintoasingleapplication.
7SIPMessages
SIPisatext-basedprotocolandusestheUTF-8charset(RFC2279
[7]).
Rosenberg,et.al.StandardsTrack[Page26]
RFC3261SIP:SessionInitiationProtocolJune2002
ASIPmessageiseitherarequestfromaclienttoaserver,ora
responsefromaservertoaclient.
BothRequest(section7.1)andResponse(section7.2)messagesuse
thebasicformatofRFC2822[3],eventhoughthesyntaxdiffersin
charactersetandsyntaxspecifics.(SIPallowsheaderfieldsthat
wouldnotbevalidRFC2822headerfields,forexample.)Bothtypes
ofmessagesconsistofastart-line,oneormoreheaderfields,an
emptylineindicatingtheendoftheheaderfields,andanoptional
message-body.
generic-message=start-line
*message-header
CRLF
[message-body]
start-line=Request-Line/Status-Line
Thestart-line,eachmessage-headerline,andtheemptylineMUSTbe
terminatedbyacarriage-returnline-feedsequence(CRLF).Notethat
theemptylineMUSTbepresentevenifthemessage-bodyisnot.
Exceptfortheabovedifferenceincharactersets,muchofSIP's
messageandheaderfieldsyntaxisidenticaltoHTTP/1.1.Rather
thanrepeatingthesyntaxandsemanticshere,weuse[HX.Y]torefer
toSectionX.YofthecurrentHTTP/1.1specification(RFC2616[8]).
However,SIPisnotanextensionofHTTP.
7.1Requests
SIPrequestsaredistinguishedbyhavingaRequest-Lineforastart-
line.ARequest-Linecontainsamethodname,aRequest-URI,andthe
protocolversionseparatedbyasinglespace(SP)character.
TheRequest-LineendswithCRLF.NoCRorLFareallowedexceptin
theend-of-lineCRLFsequence.Nolinearwhitespace(LWS)isallowed
inanyoftheelements.
Request-Line=MethodSPRequest-URISPSIP-VersionCRLF
Method:Thisspecificationdefinessixmethods:REGISTERfor
registeringcontactinformation,INVITE,ACK,andCANCELfor
settingupsessions,BYEforterminatingsessions,and
OPTIONSforqueryingserversabouttheircapabilities.SIP
extensions,documentedinstandardstrackRFCs,maydefine
additionalmethods.
Rosenberg,et.al.StandardsTrack[Page27]
RFC3261SIP:SessionInitiationProtocolJune2002
Request-URI:TheRequest-URIisaSIPorSIPSURIasdescribedin
Section19.1orageneralURI(RFC2396[5]).Itindicates
theuserorservicetowhichthisrequestisbeingaddressed.
TheRequest-URIMUSTNOTcontainunescapedspacesorcontrol
charactersandMUSTNOTbeenclosedin"<>".
SIPelementsMAYsupportRequest-URIswithschemesotherthan
"sip"and"sips",forexamplethe"tel"URIschemeofRFC
2806[9].SIPelementsMAYtranslatenon-SIPURIsusingany
mechanismattheirdisposal,resultinginSIPURI,SIPSURI,
orsomeotherscheme.
SIP-Version:Bothrequestandresponsemessagesincludethe
versionofSIPinuse,andfollow[H3.1](withHTTPreplaced
bySIP,andHTTP/1.1replacedbySIP/2.0)regardingversion
ordering,compliancerequirements,andupgradingofversion
numbers.Tobecompliantwiththisspecification,
applicationssendingSIPmessagesMUSTincludeaSIP-Version
of"SIP/2.0".TheSIP-Versionstringiscase-insensitive,
butimplementationsMUSTsendupper-case.
UnlikeHTTP/1.1,SIPtreatstheversionnumberasaliteral
string.Inpractice,thisshouldmakenodifference.
7.2Responses
SIPresponsesaredistinguishedfromrequestsbyhavingaStatus-Line
astheirstart-line.AStatus-Lineconsistsoftheprotocolversion
followedbyanumericStatus-Codeanditsassociatedtextualphrase,
witheachelementseparatedbyasingleSPcharacter.
NoCRorLFisallowedexceptinthefinalCRLFsequence.
Status-Line=SIP-VersionSPStatus-CodeSPReason-PhraseCRLF
TheStatus-Codeisa3-digitintegerresultcodethatindicatesthe
outcomeofanattempttounderstandandsatisfyarequest.The
Reason-Phraseisintendedtogiveashorttextualdescriptionofthe
Status-Code.TheStatus-Codeisintendedforusebyautomata,
whereastheReason-Phraseisintendedforthehumanuser.Aclient
isnotrequiredtoexamineordisplaytheReason-Phrase.
Whilethisspecificationsuggestsspecificwordingforthereason
phrase,implementationsMAYchooseothertext,forexample,inthe
languageindicatedintheAccept-Languageheaderfieldofthe
request.
Rosenberg,et.al.StandardsTrack[Page28]
RFC3261SIP:SessionInitiationProtocolJune2002
ThefirstdigitoftheStatus-Codedefinestheclassofresponse.
Thelasttwodigitsdonothaveanycategorizationrole.Forthis
reason,anyresponsewithastatuscodebetween100and199is
referredtoasa"1xxresponse",anyresponsewithastatuscode
between200and299asa"2xxresponse",andsoon.SIP/2.0allows
sixvaluesforthefirstdigit:
1xx:Provisional--requestreceived,continuingtoprocessthe
request;
2xx:Success--theactionwassuccessfullyreceived,understood,
andaccepted;
3xx:Redirection--furtheractionneedstobetakeninorderto
completetherequest;
4xx:ClientError--therequestcontainsbadsyntaxorcannotbe
fulfilledatthisserver;
5xx:ServerError--theserverfailedtofulfillanapparently
validrequest;
6xx:GlobalFailure--therequestcannotbefulfilledatany
server.
Section21definestheseclassesanddescribestheindividualcodes.
7.3HeaderFields
SIPheaderfieldsaresimilartoHTTPheaderfieldsinbothsyntax
andsemantics.Inparticular,SIPheaderfieldsfollowthe[H4.2]
definitionsofsyntaxforthemessage-headerandtherulesfor
extendingheaderfieldsovermultiplelines.However,thelatteris
specifiedinHTTPwithimplicitwhitespaceandfolding.This
specificationconformstoRFC2234[10]andusesonlyexplicit
whitespaceandfoldingasanintegralpartofthegrammar.
[H4.2]alsospecifiesthatmultipleheaderfieldsofthesamefield
namewhosevalueisacomma-separatedlistcanbecombinedintoone
headerfield.ThatappliestoSIPaswell,butthespecificruleis
differentbecauseofthedifferentgrammars.Specifically,anySIP
headerwhosegrammarisoftheform
header="header-name"HCOLONheader-value*(COMMAheader-value)
allowsforcombiningheaderfieldsofthesamenameintoacomma-
separatedlist.TheContactheaderfieldallowsacomma-separated
listunlesstheheaderfieldvalueis"*".
Rosenberg,et.al.StandardsTrack[Page29]
RFC3261SIP:SessionInitiationProtocolJune2002
7.3.1HeaderFieldFormat
Headerfieldsfollowthesamegenericheaderformatasthatgivenin
Section 2.2ofRFC2822[3].Eachheaderfieldconsistsofafield
namefollowedbyacolon(":")andthefieldvalue.
field-name:field-value
Theformalgrammarforamessage-headerspecifiedinSection25
allowsforanarbitraryamountofwhitespaceoneithersideofthe
colon;however,implementationsshouldavoidspacesbetweenthefield
nameandthecolonanduseasinglespace(SP)betweenthecolonand
thefield-value.
Subject:lunch
Subject:lunch
Subject:lunch
Subject:lunch
Thus,theaboveareallvalidandequivalent,butthelastisthe
preferredform.
Headerfieldscanbeextendedovermultiplelinesbyprecedingeach
extralinewithatleastoneSPorhorizontaltab(HT).Theline
breakandthewhitespaceatthebeginningofthenextlineare
treatedasasingleSPcharacter.Thus,thefollowingare
equivalent:
Subject:Iknowyou'rethere,pickupthephoneandtalktome!
Subject:Iknowyou'rethere,
pickupthephone
andtalktome!
Therelativeorderofheaderfieldswithdifferentfieldnamesisnot
significant.However,itisRECOMMENDEDthatheaderfieldswhichare
neededforproxyprocessing(Via,Route,Record-Route,Proxy-Require,
Max-Forwards,andProxy-Authorization,forexample)appeartowards
thetopofthemessagetofacilitaterapidparsing.Therelative
orderofheaderfieldrowswiththesamefieldnameisimportant.
Multipleheaderfieldrowswiththesamefield-nameMAYbepresentin
amessageifandonlyiftheentirefield-valueforthatheaderfield
isdefinedasacomma-separatedlist(thatis,iffollowsthegrammar
definedinSection7.3).ItMUSTbepossibletocombinethemultiple
headerfieldrowsintoone"field-name:field-value"pair,without
changingthesemanticsofthemessage,byappendingeachsubsequent
field-valuetothefirst,eachseparatedbyacomma.Theexceptions
tothisrulearetheWWW-Authenticate,Authorization,Proxy-
Authenticate,andProxy-Authorizationheaderfields.Multipleheader
Rosenberg,et.al.StandardsTrack[Page30]
RFC3261SIP:SessionInitiationProtocolJune2002
fieldrowswiththesenamesMAYbepresentinamessage,butsince
theirgrammardoesnotfollowthegeneralformlistedinSection7.3,
theyMUSTNOTbecombinedintoasingleheaderfieldrow.
ImplementationsMUSTbeabletoprocessmultipleheaderfieldrows
withthesamenameinanycombinationofthesingle-value-per-lineor
comma-separatedvalueforms.
Thefollowinggroupsofheaderfieldrowsarevalidandequivalent:
Route:
Subject:Lunch
Route:
Route:
Route:,
Route:
Subject:Lunch
Subject:Lunch
Route:,,
Eachofthefollowingblocksisvalidbutnotequivalenttothe
others:
Route:
Route:
Route:
Route:
Route:
Route:
Route:,,
Theformatofaheaderfield-valueisdefinedperheader-name.It
willalwaysbeeitheranopaquesequenceofTEXT-UTF8octets,ora
combinationofwhitespace,tokens,separators,andquotedstrings.
Manyexistingheaderfieldswilladheretothegeneralformofa
valuefollowedbyasemi-colonseparatedsequenceofparameter-name,
parameter-valuepairs:
field-name:field-value*(;parameter-name=parameter-value)
Rosenberg,et.al.StandardsTrack[Page31]
RFC3261SIP:SessionInitiationProtocolJune2002
Eventhoughanarbitrarynumberofparameterpairsmaybeattachedto
aheaderfieldvalue,anygivenparameter-nameMUSTNOTappearmore
thanonce.
Whencomparingheaderfields,fieldnamesarealwayscase-
insensitive.Unlessotherwisestatedinthedefinitionofa
particularheaderfield,fieldvalues,parameternames,andparameter
valuesarecase-insensitive.Tokensarealwayscase-insensitive.
Unlessspecifiedotherwise,valuesexpressedasquotedstringsare
case-sensitive.Forexample,
Contact:;expires=3600
isequivalentto
CONTACT:;ExPiReS=3600
and
Content-Disposition:session;handling=optional
isequivalentto
content-disposition:Session;HANDLING=OPTIONAL
Thefollowingtwoheaderfieldsarenotequivalent:
Warning:370devnull"Chooseabiggerpipe"
Warning:370devnull"CHOOSEABIGGERPIPE"
7.3.2HeaderFieldClassification
Someheaderfieldsonlymakesenseinrequestsorresponses.These
arecalledrequestheaderfieldsandresponseheaderfields,
respectively.Ifaheaderfieldappearsinamessagenotmatching
itscategory(suchasarequestheaderfieldinaresponse),itMUST
beignored.Section20definestheclassificationofeachheader
field.
7.3.3CompactForm
SIPprovidesamechanismtorepresentcommonheaderfieldnamesinan
abbreviatedform.Thismaybeusefulwhenmessageswouldotherwise
becometoolargetobecarriedonthetransportavailabletoit
(exceedingthemaximumtransmissionunit(MTU)whenusingUDP,for
example).ThesecompactformsaredefinedinSection20.Acompact
formMAYbesubstitutedforthelongerformofaheaderfieldnameat
anytimewithoutchangingthesemanticsofthemessage.Aheader
Rosenberg,et.al.StandardsTrack[Page32]
RFC3261SIP:SessionInitiationProtocolJune2002
fieldnameMAYappearinbothlongandshortformswithinthesame
message.ImplementationsMUSTacceptboththelongandshortforms
ofeachheadername.
7.4Bodies
Requests,includingnewrequestsdefinedinextensionstothis
specification,MAYcontainmessagebodiesunlessotherwisenoted.
Theinterpretationofthebodydependsontherequestmethod.
Forresponsemessages,therequestmethodandtheresponsestatus
codedeterminethetypeandinterpretationofanymessagebody.All
responsesMAYincludeabody.
7.4.1MessageBodyType
TheInternetmediatypeofthemessagebodyMUSTbegivenbythe
Content-Typeheaderfield.Ifthebodyhasundergoneanyencoding
suchascompression,thenthisMUSTbeindicatedbytheContent-
Encodingheaderfield;otherwise,Content-EncodingMUSTbeomitted.
Ifapplicable,thecharactersetofthemessagebodyisindicatedas
partoftheContent-Typeheader-fieldvalue.
The"multipart"MIMEtypedefinedinRFC2046[11]MAYbeusedwithin
thebodyofthemessage.Implementationsthatsendrequests
containingmultipartmessagebodiesMUSTsendasessiondescription
asanon-multipartmessagebodyiftheremoteimplementationrequests
thisthroughanAcceptheaderfieldthatdoesnotcontainmultipart.
SIPmessagesMAYcontainbinarybodiesorbodyparts.Whenno
explicitcharsetparameterisprovidedbythesender,mediasubtypes
ofthe"text"typearedefinedtohaveadefaultcharsetvalueof
"UTF-8".
7.4.2MessageBodyLength
ThebodylengthinbytesisprovidedbytheContent-Lengthheader
field.Section20.14describesthenecessarycontentsofthisheader
fieldindetail.
The"chunked"transferencodingofHTTP/1.1MUSTNOTbeusedforSIP.
(Note:Thechunkedencodingmodifiesthebodyofamessageinorder
totransferitasaseriesofchunks,eachwithitsownsize
indicator.)
Rosenberg,et.al.StandardsTrack[Page33]
RFC3261SIP:SessionInitiationProtocolJune2002
7.5FramingSIPMessages
UnlikeHTTP,SIPimplementationscanuseUDPorotherunreliable
datagramprotocols.Eachsuchdatagramcarriesonerequestor
response.SeeSection18onconstraintsonusageofunreliable
transports.
ImplementationsprocessingSIPmessagesoverstream-oriented
transportsMUSTignoreanyCRLFappearingbeforethestart-line
[H4.1].
TheContent-Lengthheaderfieldvalueisusedtolocatetheendof
eachSIPmessageinastream.ItwillalwaysbepresentwhenSIP
messagesaresentoverstream-orientedtransports.
8GeneralUserAgentBehavior
Auseragentrepresentsanendsystem.Itcontainsauseragent
client(UAC),whichgeneratesrequests,andauseragentserver
(UAS),whichrespondstothem.AUACiscapableofgeneratinga
requestbasedonsomeexternalstimulus(theuserclickingabutton,
orasignalonaPSTNline)andprocessingaresponse.AUASis
capableofreceivingarequestandgeneratingaresponsebasedon
userinput,externalstimulus,theresultofaprogramexecution,or
someothermechanism.
WhenaUACsendsarequest,therequestpassesthroughsomenumberof
proxyservers,whichforwardtherequesttowardstheUAS.Whenthe
UASgeneratesaresponse,theresponseisforwardedtowardstheUAC.
UACandUASproceduresdependstronglyontwofactors.First,based
onwhethertherequestorresponseisinsideoroutsideofadialog,
andsecond,basedonthemethodofarequest.Dialogsarediscussed
thoroughlyinSection12;theyrepresentapeer-to-peerrelationship
betweenuseragentsandareestablishedbyspecificSIPmethods,such
asINVITE.
Inthissection,wediscussthemethod-independentrulesforUACand
UASbehaviorwhenprocessingrequeststhatareoutsideofadialog.
Thisincludes,ofcourse,therequestswhichthemselvesestablisha
dialog.
Securityproceduresforrequestsandresponsesoutsideofadialog
aredescribedinSection26.Specifically,mechanismsexistforthe
UASandUACtomutuallyauthenticate.Alimitedsetofprivacy
featuresarealsosupportedthroughencryptionofbodiesusing
S/MIME.
Rosenberg,et.al.StandardsTrack[Page34]
RFC3261SIP:SessionInitiationProtocolJune2002
8.1UACBehavior
ThissectioncoversUACbehavioroutsideofadialog.
8.1.1GeneratingtheRequest
AvalidSIPrequestformulatedbyaUACMUST,ataminimum,contain
thefollowingheaderfields:To,From,CSeq,Call-ID,Max-Forwards,
andVia;alloftheseheaderfieldsaremandatoryinallSIP
requests.Thesesixheaderfieldsarethefundamentalbuilding
blocksofaSIPmessage,astheyjointlyprovideformostofthe
criticalmessageroutingservicesincludingtheaddressingof
messages,theroutingofresponses,limitingmessagepropagation,
orderingofmessages,andtheuniqueidentificationoftransactions.
Theseheaderfieldsareinadditiontothemandatoryrequestline,
whichcontainsthemethod,Request-URI,andSIPversion.
ExamplesofrequestssentoutsideofadialogincludeanINVITEto
establishasession(Section13)andanOPTIONStoqueryfor
capabilities(Section11).
8.1.1.1Request-URI
TheinitialRequest-URIofthemessageSHOULDbesettothevalueof
theURIintheTofield.OnenotableexceptionistheREGISTER
method;behaviorforsettingtheRequest-URIofREGISTERisgivenin
Section10.Itmayalsobeundesirableforprivacyreasonsor
conveniencetosetthesefieldstothesamevalue(especiallyifthe
originatingUAexpectsthattheRequest-URIwillbechangedduring
transit).
Insomespecialcircumstances,thepresenceofapre-existingroute
setcanaffecttheRequest-URIofthemessage.Apre-existingroute
setisanorderedsetofURIsthatidentifyachainofservers,to
whichaUACwillsendoutgoingrequeststhatareoutsideofadialog.
Commonly,theyareconfiguredontheUAbyauserorserviceprovider
manually,orthroughsomeothernon-SIPmechanism.Whenaprovider
wishestoconfigureaUAwithanoutboundproxy,itisRECOMMENDED
thatthisbedonebyprovidingitwithapre-existingroutesetwith
asingleURI,thatoftheoutboundproxy.
Whenapre-existingroutesetispresent,theproceduresfor
populatingtheRequest-URIandRouteheaderfielddetailedinSection
12.2.1.1MUSTbefollowed(eventhoughthereisnodialog),usingthe
desiredRequest-URIastheremotetargetURI.
Rosenberg,et.al.StandardsTrack[Page35]
RFC3261SIP:SessionInitiationProtocolJune2002
8.1.1.2To
TheToheaderfieldfirstandforemostspecifiesthedesired
"logical"recipientoftherequest,ortheaddress-of-recordofthe
userorresourcethatisthetargetofthisrequest.Thismayormay
notbetheultimaterecipientoftherequest.TheToheaderfield
MAYcontainaSIPorSIPSURI,butitmayalsomakeuseofotherURI
schemes(thetelURL(RFC2806[9]),forexample)whenappropriate.
AllSIPimplementationsMUSTsupporttheSIPURIscheme.Any
implementationthatsupportsTLSMUSTsupporttheSIPSURIscheme.
TheToheaderfieldallowsforadisplayname.
AUACmaylearnhowtopopulatetheToheaderfieldforaparticular
requestinanumberofways.UsuallytheuserwillsuggesttheTo
headerfieldthroughahumaninterface,perhapsinputtingtheURI
manuallyorselectingitfromsomesortofaddressbook.Frequently,
theuserwillnotenteracompleteURI,butratherastringofdigits
orletters(forexample,"bob").ItisatthediscretionoftheUA
tochoosehowtointerpretthisinput.Usingthestringtoformthe
userpartofaSIPURIimpliesthattheUAwishesthenametobe
resolvedinthedomaintotheright-handside(RHS)oftheat-signin
theSIPURI(forinstance,sip:[email protected]).Usingthestringto
formtheuserpartofaSIPSURIimpliesthattheUAwishesto
communicatesecurely,andthatthenameistoberesolvedinthe
domaintotheRHSoftheat-sign.TheRHSwillfrequentlybethe
homedomainoftherequestor,whichallowsforthehomedomainto
processtheoutgoingrequest.Thisisusefulforfeatureslike
"speeddial"thatrequireinterpretationoftheuserpartinthehome
domain.ThetelURLmaybeusedwhentheUAdoesnotwishtospecify
thedomainthatshouldinterpretatelephonenumberthathasbeen
inputbytheuser.Rather,eachdomainthroughwhichtherequest
passeswouldbegiventhatopportunity.Asanexample,auserinan
airportmightloginandsendrequeststhroughanoutboundproxyin
theairport.Iftheyenter"411"(thisisthephonenumberforlocal
directoryassistanceintheUnitedStates),thatneedstobe
interpretedandprocessedbytheoutboundproxyintheairport,not
theuser'shomedomain.Inthiscase,tel:411wouldbetheright
choice.
ArequestoutsideofadialogMUSTNOTcontainaTotag;thetagin
theTofieldofarequestidentifiesthepeerofthedialog.Since
nodialogisestablished,notagispresent.
ForfurtherinformationontheToheaderfield,seeSection20.39.
ThefollowingisanexampleofavalidToheaderfield:
To:Carol
Rosenberg,et.al.StandardsTrack[Page36]
RFC3261SIP:SessionInitiationProtocolJune2002
8.1.1.3From
TheFromheaderfieldindicatesthelogicalidentityoftheinitiator
oftherequest,possiblytheuser'saddress-of-record.LiketheTo
headerfield,itcontainsaURIandoptionallyadisplayname.Itis
usedbySIPelementstodeterminewhichprocessingrulestoapplyto
arequest(forexample,automaticcallrejection).Assuch,itis
veryimportantthattheFromURInotcontainIPaddressesortheFQDN
ofthehostonwhichtheUAisrunning,sincethesearenotlogical
names.
TheFromheaderfieldallowsforadisplayname.AUACSHOULDuse
thedisplayname"Anonymous",alongwithasyntacticallycorrect,but
otherwisemeaninglessURI(likesip:[email protected]),ifthe
identityoftheclientistoremainhidden.
Usually,thevaluethatpopulatestheFromheaderfieldinrequests
generatedbyaparticularUAispre-provisionedbytheuserorbythe
administratorsoftheuser'slocaldomain.IfaparticularUAis
usedbymultipleusers,itmighthaveswitchableprofilesthat
includeaURIcorrespondingtotheidentityoftheprofileduser.
Recipientsofrequestscanauthenticatetheoriginatorofarequest
inordertoascertainthattheyarewhotheirFromheaderfield
claimstheyare(seeSection22formoreonauthentication).
TheFromfieldMUSTcontainanew"tag"parameter,chosenbytheUAC.
SeeSection19.3fordetailsonchoosingatag.
ForfurtherinformationontheFromheaderfield,seeSection20.20.
Examples:
From:"Bob";tag=a48s
From:sip:[email protected];tag=887s
From:Anonymous;tag=hyh8
8.1.1.4Call-ID
TheCall-IDheaderfieldactsasauniqueidentifiertogroup
togetheraseriesofmessages.ItMUSTbethesameforallrequests
andresponsessentbyeitherUAinadialog.ItSHOULDbethesame
ineachregistrationfromaUA.
InanewrequestcreatedbyaUACoutsideofanydialog,theCall-ID
headerfieldMUSTbeselectedbytheUACasagloballyunique
identifieroverspaceandtimeunlessoverriddenbymethod-specific
behavior.AllSIPUAsmusthaveameanstoguaranteethattheCall-
IDheaderfieldstheyproducewillnotbeinadvertentlygeneratedby
anyotherUA.Notethatwhenrequestsareretriedaftercertain
Rosenberg,et.al.StandardsTrack[Page37]
RFC3261SIP:SessionInitiationProtocolJune2002
failureresponsesthatsolicitanamendmenttoarequest(for
example,achallengeforauthentication),theseretriedrequestsare
notconsiderednewrequests,andthereforedonotneednewCall-ID
headerfields;seeSection8.1.3.5.
Useofcryptographicallyrandomidentifiers(RFC1750[12])inthe
generationofCall-IDsisRECOMMENDED.ImplementationsMAYusethe
form"localid@host".Call-IDsarecase-sensitiveandaresimply
comparedbyte-by-byte.
Usingcryptographicallyrandomidentifiersprovidessome
protectionagainstsessionhijackingandreducesthelikelihoodof
unintentionalCall-IDcollisions.
Noprovisioningorhumaninterfaceisrequiredfortheselectionof
theCall-IDheaderfieldvalueforarequest.
ForfurtherinformationontheCall-IDheaderfield,seeSection
20.8.
Example:
Call-ID:[email protected]
8.1.1.5CSeq
TheCSeqheaderfieldservesasawaytoidentifyandorder
transactions.Itconsistsofasequencenumberandamethod.The
methodMUSTmatchthatoftherequest.Fornon-REGISTERrequests
outsideofadialog,thesequencenumbervalueisarbitrary.The
sequencenumbervalueMUSTbeexpressibleasa32-bitunsigned
integerandMUSTbelessthan2**31.Aslongasitfollowstheabove
guidelines,aclientmayuseanymechanismitwouldliketoselect
CSeqheaderfieldvalues.
Section12.2.1.1discussesconstructionoftheCSeqforrequests
withinadialog.
Example:
CSeq:4711INVITE
Rosenberg,et.al.StandardsTrack[Page38]
RFC3261SIP:SessionInitiationProtocolJune2002
8.1.1.6Max-Forwards
TheMax-Forwardsheaderfieldservestolimitthenumberofhopsa
requestcantransitonthewaytoitsdestination.Itconsistsofan
integerthatisdecrementedbyoneateachhop.IftheMax-Forwards
valuereaches0beforetherequestreachesitsdestination,itwill
berejectedwitha483(TooManyHops)errorresponse.
AUACMUSTinsertaMax-Forwardsheaderfieldintoeachrequestit
originateswithavaluethatSHOULDbe70.Thisnumberwaschosento
besufficientlylargetoguaranteethatarequestwouldnotbe
droppedinanySIPnetworkwhentherewerenoloops,butnotsolarge
astoconsumeproxyresourceswhenaloopdoesoccur.Lowervalues
shouldbeusedwithcautionandonlyinnetworkswheretopologiesare
knownbytheUA.
8.1.1.7Via
TheViaheaderfieldindicatesthetransportusedforthetransaction
andidentifiesthelocationwheretheresponseistobesent.AVia
headerfieldvalueisaddedonlyafterthetransportthatwillbe
usedtoreachthenexthophasbeenselected(whichmayinvolvethe
usageoftheproceduresin[4]).
WhentheUACcreatesarequest,itMUSTinsertaViaintothat
request.Theprotocolnameandprotocolversionintheheaderfield
MUSTbeSIPand2.0,respectively.TheViaheaderfieldvalueMUST
containabranchparameter.Thisparameterisusedtoidentifythe
transactioncreatedbythatrequest.Thisparameterisusedbyboth
theclientandtheserver.
ThebranchparametervalueMUSTbeuniqueacrossspaceandtimefor
allrequestssentbytheUA.TheexceptionstothisruleareCANCEL
andACKfornon-2xxresponses.Asdiscussedbelow,aCANCELrequest
willhavethesamevalueofthebranchparameterastherequestit
cancels.AsdiscussedinSection17.1.1.3,anACKforanon-2xx
responsewillalsohavethesamebranchIDastheINVITEwhose
responseitacknowledges.
TheuniquenesspropertyofthebranchIDparameter,tofacilitate
itsuseasatransactionID,wasnotpartofRFC2543.
ThebranchIDinsertedbyanelementcompliantwiththis
specificationMUSTalwaysbeginwiththecharacters"z9hG4bK".These
7charactersareusedasamagiccookie(7isdeemedsufficientto
ensurethatanolderRFC2543implementationwouldnotpicksucha
value),sothatserversreceivingtherequestcandeterminethatthe
branchIDwasconstructedinthefashiondescribedbythis
Rosenberg,et.al.StandardsTrack[Page39]
RFC3261SIP:SessionInitiationProtocolJune2002
specification(thatis,globallyunique).Beyondthisrequirement,
thepreciseformatofthebranchtokenisimplementation-defined.
TheViaheadermaddr,ttl,andsent-bycomponentswillbesetwhen
therequestisprocessedbythetransportlayer(Section18).
ViaprocessingforproxiesisdescribedinSection16.6Item8and
Section16.7Item3.
8.1.1.8Contact
TheContactheaderfieldprovidesaSIPorSIPSURIthatcanbeused
tocontactthatspecificinstanceoftheUAforsubsequentrequests.
TheContactheaderfieldMUSTbepresentandcontainexactlyoneSIP
orSIPSURIinanyrequestthatcanresultintheestablishmentofa
dialog.Forthemethodsdefinedinthisspecification,thatincludes
onlytheINVITErequest.Fortheserequests,thescopeofthe
Contactisglobal.Thatis,theContactheaderfieldvaluecontains
theURIatwhichtheUAwouldliketoreceiverequests,andthisURI
MUSTbevalidevenifusedinsubsequentrequestsoutsideofany
dialogs.
IftheRequest-URIortopRouteheaderfieldvaluecontainsaSIPS
URI,theContactheaderfieldMUSTcontainaSIPSURIaswell.
ForfurtherinformationontheContactheaderfield,seeSection
20.10.
8.1.1.9SupportedandRequire
IftheUACsupportsextensionstoSIPthatcanbeappliedbythe
servertotheresponse,theUACSHOULDincludeaSupportedheader
fieldintherequestlistingtheoptiontags(Section19.2)forthose
extensions.
TheoptiontagslistedMUSTonlyrefertoextensionsdefinedin
standards-trackRFCs.Thisistopreventserversfrominsistingthat
clientsimplementnon-standard,vendor-definedfeaturesinorderto
receiveservice.Extensionsdefinedbyexperimentaland
informationalRFCsareexplicitlyexcludedfromusagewiththe
Supportedheaderfieldinarequest,sincetheytooareoftenusedto
documentvendor-definedextensions.
IftheUACwishestoinsistthataUASunderstandanextensionthat
theUACwillapplytotherequestinordertoprocesstherequest,it
MUSTinsertaRequireheaderfieldintotherequestlistingthe
optiontagforthatextension.IftheUACwishestoapplyan
extensiontotherequestandinsistthatanyproxiesthatare
Rosenberg,et.al.StandardsTrack[Page40]
RFC3261SIP:SessionInitiationProtocolJune2002
traversedunderstandthatextension,itMUSTinsertaProxy-Require
headerfieldintotherequestlistingtheoptiontagforthat
extension.
AswiththeSupportedheaderfield,theoptiontagsintheRequire
andProxy-RequireheaderfieldsMUSTonlyrefertoextensionsdefined
instandards-trackRFCs.
8.1.1.10AdditionalMessageComponents
Afteranewrequesthasbeencreated,andtheheaderfieldsdescribed
abovehavebeenproperlyconstructed,anyadditionaloptionalheader
fieldsareadded,asareanyheaderfieldsspecifictothemethod.
SIPrequestsMAYcontainaMIME-encodedmessage-body.Regardlessof
thetypeofbodythatarequestcontains,certainheaderfieldsmust
beformulatedtocharacterizethecontentsofthebody.Forfurther
informationontheseheaderfields,seeSections20.11through20.15.
8.1.2SendingtheRequest
Thedestinationfortherequestisthencomputed.Unlessthereis
localpolicyspecifyingotherwise,thedestinationMUSTbedetermined
byapplyingtheDNSproceduresdescribedin[4]asfollows.Ifthe
firstelementintheroutesetindicatedastrictrouter(resulting
informingtherequestasdescribedinSection12.2.1.1),the
proceduresMUSTbeappliedtotheRequest-URIoftherequest.
Otherwise,theproceduresareappliedtothefirstRouteheaderfield
valueintherequest(ifoneexists),ortotherequest'sRequest-URI
ifthereisnoRouteheaderfieldpresent.Theseproceduresyieldan
orderedsetofaddress,port,andtransportstoattempt.Independent
ofwhichURIisusedasinputtotheproceduresof[4],ifthe
Request-URIspecifiesaSIPSresource,theUACMUSTfollowthe
proceduresof[4]asiftheinputURIwereaSIPSURI.
LocalpolicyMAYspecifyanalternatesetofdestinationstoattempt.
IftheRequest-URIcontainsaSIPSURI,anyalternatedestinations
MUSTbecontactedwithTLS.Beyondthat,therearenorestrictions
onthealternatedestinationsiftherequestcontainsnoRouteheader
field.Thisprovidesasimplealternativetoapre-existingroute
setasawaytospecifyanoutboundproxy.However,thatapproach
forconfiguringanoutboundproxyisNOTRECOMMENDED;apre-existing
routesetwithasingleURISHOULDbeusedinstead.Iftherequest
containsaRouteheaderfield,therequestSHOULDbesenttothe
locationsderivedfromitstopmostvalue,butMAYbesenttoany
serverthattheUAiscertainwillhonortheRouteandRequest-URI
policiesspecifiedinthisdocument(asopposedtothoseinRFC
2543).Inparticular,aUACconfiguredwithanoutboundproxySHOULD
Rosenberg,et.al.StandardsTrack[Page41]
RFC3261SIP:SessionInitiationProtocolJune2002
attempttosendtherequesttothelocationindicatedinthefirst
Routeheaderfieldvalueinsteadofadoptingthepolicyofsending
allmessagestotheoutboundproxy.
ThisensuresthatoutboundproxiesthatdonotaddRecord-Route
headerfieldvalueswilldropoutofthepathofsubsequent
requests.ItallowsendpointsthatcannotresolvethefirstRoute
URItodelegatethattasktoanoutboundproxy.
TheUACSHOULDfollowtheproceduresdefinedin[4]forstateful
elements,tryingeachaddressuntilaserveriscontacted.Eachtry
constitutesanewtransaction,andthereforeeachcarriesadifferent
topmostViaheaderfieldvaluewithanewbranchparameter.
Furthermore,thetransportvalueintheViaheaderfieldissetto
whatevertransportwasdeterminedforthetargetserver.
8.1.3ProcessingResponses
Responsesarefirstprocessedbythetransportlayerandthenpassed
uptothetransactionlayer.Thetransactionlayerperformsits
processingandthenpassestheresponseuptotheTU.Themajority
ofresponseprocessingintheTUismethodspecific.However,there
aresomegeneralbehaviorsindependentofthemethod.
8.1.3.1TransactionLayerErrors
Insomecases,theresponsereturnedbythetransactionlayerwill
notbeaSIPmessage,butratheratransactionlayererror.Whena
timeouterrorisreceivedfromthetransactionlayer,itMUSTbe
treatedasifa408(RequestTimeout)statuscodehasbeenreceived.
Ifafataltransporterrorisreportedbythetransportlayer
(generally,duetofatalICMPerrorsinUDPorconnectionfailuresin
TCP),theconditionMUSTbetreatedasa503(ServiceUnavailable)
statuscode.
8.1.3.2UnrecognizedResponses
AUACMUSTtreatanyfinalresponseitdoesnotrecognizeasbeing
equivalenttothex00responsecodeofthatclass,andMUSTbeable
toprocessthex00responsecodeforallclasses.Forexample,ifa
UACreceivesanunrecognizedresponsecodeof431,itcansafely
assumethattherewassomethingwrongwithitsrequestandtreatthe
responseasifithadreceiveda400(BadRequest)responsecode.A
UACMUSTtreatanyprovisionalresponsedifferentthan100thatit
doesnotrecognizeas183(SessionProgress).AUACMUSTbeableto
process100and183responses.
Rosenberg,et.al.StandardsTrack[Page42]
RFC3261SIP:SessionInitiationProtocolJune2002
8.1.3.3Vias
IfmorethanoneViaheaderfieldvalueispresentinaresponse,the
UACSHOULDdiscardthemessage.
ThepresenceofadditionalViaheaderfieldvaluesthatprecede
theoriginatoroftherequestsuggeststhatthemessagewas
misroutedorpossiblycorrupted.
8.1.3.4Processing3xxResponses
Uponreceiptofaredirectionresponse(forexample,a301response
statuscode),clientsSHOULDusetheURI(s)intheContactheader
fieldtoformulateoneormorenewrequestsbasedontheredirected
request.Thisprocessissimilartothatofaproxyrecursingona
3xxclassresponseasdetailedinSections16.5and16.6.Aclient
startswithaninitialtargetsetcontainingexactlyoneURI,the
Request-URIoftheoriginalrequest.Ifaclientwishestoformulate
newrequestsbasedona3xxclassresponsetothatrequest,itplaces
theURIstotryintothetargetset.Subjecttotherestrictionsin
thisspecification,aclientcanchoosewhichContactURIsitplaces
intothetargetset.Aswithproxyrecursion,aclientprocessing
3xxclassresponsesMUSTNOTaddanygivenURItothetargetsetmore
thanonce.IftheoriginalrequesthadaSIPSURIintheRequest-
URI,theclientMAYchoosetorecursetoanon-SIPSURI,butSHOULD
informtheuseroftheredirectiontoaninsecureURI.
Anynewrequestmayreceive3xxresponsesthemselvescontaining
theoriginalURIasacontact.Twolocationscanbeconfiguredto
redirecttoeachother.PlacinganygivenURIinthetargetset
onlyoncepreventsinfiniteredirectionloops.
Asthetargetsetgrows,theclientMAYgeneratenewrequeststothe
URIsinanyorder.Acommonmechanismistoorderthesetbythe"q"
parametervaluefromtheContactheaderfieldvalue.Requeststothe
URIsMAYbegeneratedseriallyorinparallel.Oneapproachisto
processgroupsofdecreasingq-valuesseriallyandprocesstheURIs
ineachq-valuegroupinparallel.Anotheristoperformonlyserial
processingindecreasingq-valueorder,arbitrarilychoosingbetween
contactsofequalq-value.
Ifcontactinganaddressinthelistresultsinafailure,asdefined
inthenextparagraph,theelementmovestothenextaddressinthe
list,untilthelistisexhausted.Ifthelistisexhausted,then
therequesthasfailed.
Rosenberg,et.al.StandardsTrack[Page43]
RFC3261SIP:SessionInitiationProtocolJune2002
FailuresSHOULDbedetectedthroughfailureresponsecodes(codes
greaterthan399);fornetworkerrorstheclienttransactionwill
reportanytransportlayerfailurestothetransactionuser.Note
thatsomeresponsecodes(detailedin8.1.3.5)indicatethatthe
requestcanberetried;requeststhatarereattemptedshouldnotbe
consideredfailures.
Whenafailureforaparticularcontactaddressisreceived,the
clientSHOULDtrythenextcontactaddress.Thiswillinvolve
creatinganewclienttransactiontodeliveranewrequest.
Inordertocreatearequestbasedonacontactaddressina3xx
response,aUACMUSTcopytheentireURIfromthetargetsetintothe
Request-URI,exceptforthe"method-param"and"header"URI
parameters(seeSection19.1.1foradefinitionoftheseparameters).
Itusesthe"header"parameterstocreateheaderfieldvaluesforthe
newrequest,overwritingheaderfieldvaluesassociatedwiththe
redirectedrequestinaccordancewiththeguidelinesinSection
19.1.5.
Notethatinsomeinstances,headerfieldsthathavebeen
communicatedinthecontactaddressmayinsteadappendtoexisting
requestheaderfieldsintheoriginalredirectedrequest.Asa
generalrule,iftheheaderfieldcanacceptacomma-separatedlist
ofvalues,thenthenewheaderfieldvalueMAYbeappendedtoany
existingvaluesintheoriginalredirectedrequest.Iftheheader
fielddoesnotacceptmultiplevalues,thevalueintheoriginal
redirectedrequestMAYbeoverwrittenbytheheaderfieldvalue
communicatedinthecontactaddress.Forexample,ifacontact
addressisreturnedwiththefollowingvalue:
sip:user@host?Subject=foo&Call-Info=
ThenanySubjectheaderfieldintheoriginalredirectedrequestis
overwritten,buttheHTTPURLismerelyappendedtoanyexisting
Call-Infoheaderfieldvalues.
ItisRECOMMENDEDthattheUACreusethesameTo,From,andCall-ID
usedintheoriginalredirectedrequest,buttheUACMAYalsochoose
toupdatetheCall-IDheaderfieldvaluefornewrequests,for
example.
Finally,oncethenewrequesthasbeenconstructed,itissentusing
anewclienttransaction,andthereforeMUSThaveanewbranchIDin
thetopViafieldasdiscussedinSection8.1.1.7.
Rosenberg,et.al.StandardsTrack[Page44]
RFC3261SIP:SessionInitiationProtocolJune2002
Inallotherrespects,requestssentuponreceiptofaredirect
responseSHOULDre-usetheheaderfieldsandbodiesoftheoriginal
request.
Insomeinstances,ContactheaderfieldvaluesmaybecachedatUAC
temporarilyorpermanentlydependingonthestatuscodereceivedand
thepresenceofanexpirationinterval;seeSections21.3.2and
21.3.3.
8.1.3.5Processing4xxResponses
Certain4xxresponsecodesrequirespecificUAprocessing,
independentofthemethod.
Ifa401(Unauthorized)or407(ProxyAuthenticationRequired)
responseisreceived,theUACSHOULDfollowtheauthorization
proceduresofSection22.2andSection22.3toretrytherequestwith
credentials.
Ifa413(RequestEntityTooLarge)responseisreceived(Section
21.4.11),therequestcontainedabodythatwaslongerthantheUAS
waswillingtoaccept.Ifpossible,theUACSHOULDretrythe
request,eitheromittingthebodyorusingoneofasmallerlength.
Ifa415(UnsupportedMediaType)responseisreceived(Section
21.4.13),therequestcontainedmediatypesnotsupportedbytheUAS.
TheUACSHOULDretrysendingtherequest,thistimeonlyusing
contentwithtypeslistedintheAcceptheaderfieldintheresponse,
withencodingslistedintheAccept-Encodingheaderfieldinthe
response,andwithlanguageslistedintheAccept-Languageinthe
response.
Ifa416(UnsupportedURIScheme)responseisreceived(Section
21.4.14),theRequest-URIusedaURIschemenotsupportedbythe
server.TheclientSHOULDretrytherequest,thistime,usingaSIP
URI.
Ifa420(BadExtension)responseisreceived(Section21.4.15),the
requestcontainedaRequireorProxy-Requireheaderfieldlistingan
option-tagforafeaturenotsupportedbyaproxyorUAS.TheUAC
SHOULDretrytherequest,thistimeomittinganyextensionslistedin
theUnsupportedheaderfieldintheresponse.
Inalloftheabovecases,therequestisretriedbycreatinganew
requestwiththeappropriatemodifications.Thisnewrequest
constitutesanewtransactionandSHOULDhavethesamevalueofthe
Call-ID,To,andFromofthepreviousrequest,buttheCSeqshould
containanewsequencenumberthatisonehigherthantheprevious.
Rosenberg,et.al.StandardsTrack[Page45]
RFC3261SIP:SessionInitiationProtocolJune2002
Withother4xxresponses,includingthoseyettobedefined,aretry
mayormaynotbepossibledependingonthemethodandtheusecase.
8.2UASBehavior
WhenarequestoutsideofadialogisprocessedbyaUAS,thereisa
setofprocessingrulesthatarefollowed,independentofthemethod.
Section12givesguidanceonhowaUAScantellwhetherarequestis
insideoroutsideofadialog.
Notethatrequestprocessingisatomic.Ifarequestisaccepted,
allstatechangesassociatedwithitMUSTbeperformed.Ifitis
rejected,allstatechangesMUSTNOTbeperformed.
UASsSHOULDprocesstherequestsintheorderofthestepsthat
followinthissection(thatis,startingwithauthentication,then
inspectingthemethod,theheaderfields,andsoonthroughoutthe
remainderofthissection).
8.2.1MethodInspection
Oncearequestisauthenticated(orauthenticationisskipped),the
UASMUSTinspectthemethodoftherequest.IftheUASrecognizes
butdoesnotsupportthemethodofarequest,itMUSTgeneratea405
(MethodNotAllowed)response.Proceduresforgeneratingresponses
aredescribedinSection8.2.6.TheUASMUSTalsoaddanAllow
headerfieldtothe405(MethodNotAllowed)response.TheAllow
headerfieldMUSTlistthesetofmethodssupportedbytheUAS
generatingthemessage.TheAllowheaderfieldispresentedin
Section20.5.
Ifthemethodisonesupportedbytheserver,processingcontinues.
8.2.2HeaderInspection
IfaUASdoesnotunderstandaheaderfieldinarequest(thatis,
theheaderfieldisnotdefinedinthisspecificationorinany
supportedextension),theserverMUSTignorethatheaderfieldand
continueprocessingthemessage.AUASSHOULDignoreanymalformed
headerfieldsthatarenotnecessaryforprocessingrequests.
8.2.2.1ToandRequest-URI
TheToheaderfieldidentifiestheoriginalrecipientoftherequest
designatedbytheuseridentifiedintheFromfield.Theoriginal
recipientmayormaynotbetheUASprocessingtherequest,dueto
callforwardingorotherproxyoperations.AUASMAYapplyany
policyitwishestodeterminewhethertoacceptrequestswhentheTo
Rosenberg,et.al.StandardsTrack[Page46]
RFC3261SIP:SessionInitiationProtocolJune2002
headerfieldisnottheidentityoftheUAS.However,itis
RECOMMENDEDthataUASacceptrequestseveniftheydonotrecognize
theURIscheme(forexample,atel:URI)intheToheaderfield,or
iftheToheaderfielddoesnotaddressaknownorcurrentuserof
thisUAS.If,ontheotherhand,theUASdecidestorejectthe
request,itSHOULDgeneratearesponsewitha403(Forbidden)status
codeandpassittotheservertransactionfortransmission.
However,theRequest-URIidentifiestheUASthatistoprocessthe
request.IftheRequest-URIusesaschemenotsupportedbytheUAS,
itSHOULDrejecttherequestwitha416(UnsupportedURIScheme)
response.IftheRequest-URIdoesnotidentifyanaddressthatthe
UASiswillingtoacceptrequestsfor,itSHOULDrejecttherequest
witha404(NotFound)response.Typically,aUAthatusesthe
REGISTERmethodtobinditsaddress-of-recordtoaspecificcontact
addresswillseerequestswhoseRequest-URIequalsthatcontact
address.OtherpotentialsourcesofreceivedRequest-URIsinclude
theContactheaderfieldsofrequestsandresponsessentbytheUA
thatestablishorrefreshdialogs.
8.2.2.2MergedRequests
IftherequesthasnotagintheToheaderfield,theUAScoreMUST
checktherequestagainstongoingtransactions.IftheFromtag,
Call-ID,andCSeqexactlymatchthoseassociatedwithanongoing
transaction,buttherequestdoesnotmatchthattransaction(based
onthematchingrulesinSection17.2.3),theUAScoreSHOULD
generatea482(LoopDetected)responseandpassittotheserver
transaction.
ThesamerequesthasarrivedattheUASmorethanonce,following
differentpaths,mostlikelyduetoforking.TheUASprocesses
thefirstsuchrequestreceivedandrespondswitha482(Loop
Detected)totherestofthem.
8.2.2.3Require
AssumingtheUASdecidesthatitistheproperelementtoprocessthe
request,itexaminestheRequireheaderfield,ifpresent.
TheRequireheaderfieldisusedbyaUACtotellaUASaboutSIP
extensionsthattheUACexpectstheUAStosupportinorderto
processtherequestproperly.ItsformatisdescribedinSection
20.32.IfaUASdoesnotunderstandanoption-taglistedina
Requireheaderfield,itMUSTrespondbygeneratingaresponsewith
statuscode420(BadExtension).TheUASMUSTaddanUnsupported
headerfield,andlistinitthoseoptionsitdoesnotunderstand
amongstthoseintheRequireheaderfieldoftherequest.
Rosenberg,et.al.StandardsTrack[Page47]
RFC3261SIP:SessionInitiationProtocolJune2002
NotethatRequireandProxy-RequireMUSTNOTbeusedinaSIPCANCEL
request,orinanACKrequestsentforanon-2xxresponse.These
headerfieldsMUSTbeignorediftheyarepresentintheserequests.
AnACKrequestfora2xxresponseMUSTcontainonlythoseRequireand
Proxy-Requirevaluesthatwerepresentintheinitialrequest.
Example:
UAC->UAS:INVITEsip:[email protected]/2.0
Require:100rel
UAS->UAC:SIP/2.0420BadExtension
Unsupported:100rel
Thisbehaviorensuresthattheclient-serverinteractionwill
proceedwithoutdelaywhenalloptionsareunderstoodbyboth
sides,andonlyslowdownifoptionsarenotunderstood(asinthe
exampleabove).Forawell-matchedclient-serverpair,the
interactionproceedsquickly,savingaround-tripoftenrequired
bynegotiationmechanisms.Inaddition,italsoremovesambiguity
whentheclientrequiresfeaturesthattheserverdoesnot
understand.Somefeatures,suchascallhandlingfields,areonly
ofinteresttoendsystems.
8.2.3ContentProcessing
AssumingtheUASunderstandsanyextensionsrequiredbytheclient,
theUASexaminesthebodyofthemessage,andtheheaderfieldsthat
describeit.Ifthereareanybodieswhosetype(indicatedbythe
Content-Type),language(indicatedbytheContent-Language)or
encoding(indicatedbytheContent-Encoding)arenotunderstood,and
thatbodypartisnotoptional(asindicatedbytheContent-
Dispositionheaderfield),theUASMUSTrejecttherequestwitha415
(UnsupportedMediaType)response.TheresponseMUSTcontainan
Acceptheaderfieldlistingthetypesofallbodiesitunderstands,
intheeventtherequestcontainedbodiesoftypesnotsupportedby
theUAS.Iftherequestcontainedcontentencodingsnotunderstood
bytheUAS,theresponseMUSTcontainanAccept-Encodingheaderfield
listingtheencodingsunderstoodbytheUAS.Iftherequest
containedcontentwithlanguagesnotunderstoodbytheUAS,the
responseMUSTcontainanAccept-Languageheaderfieldindicatingthe
languagesunderstoodbytheUAS.Beyondthesechecks,bodyhandling
dependsonthemethodandtype.Forfurtherinformationonthe
processingofcontent-specificheaderfields,seeSection7.4aswell
asSection20.11through20.15.
Rosenberg,et.al.StandardsTrack[Page48]
RFC3261SIP:SessionInitiationProtocolJune2002
8.2.4ApplyingExtensions
AUASthatwishestoapplysomeextensionwhengeneratingthe
responseMUSTNOTdosounlesssupportforthatextensionis
indicatedintheSupportedheaderfieldintherequest.Ifthe
desiredextensionisnotsupported,theserverSHOULDrelyonlyon
baselineSIPandanyotherextensionssupportedbytheclient.In
rarecircumstances,wheretheservercannotprocesstherequest
withouttheextension,theserverMAYsenda421(ExtensionRequired)
response.Thisresponseindicatesthattheproperresponsecannotbe
generatedwithoutsupportofaspecificextension.Theneeded
extension(s)MUSTbeincludedinaRequireheaderfieldinthe
response.ThisbehaviorisNOTRECOMMENDED,asitwillgenerally
breakinteroperability.
Anyextensionsappliedtoanon-421responseMUSTbelistedina
Requireheaderfieldincludedintheresponse.Ofcourse,theserver
MUSTNOTapplyextensionsnotlistedintheSupportedheaderfieldin
therequest.Asaresultofthis,theRequireheaderfieldina
responsewillonlyevercontainoptiontagsdefinedinstandards-
trackRFCs.
8.2.5ProcessingtheRequest
Assumingallofthechecksintheprevioussubsectionsarepassed,
theUASprocessingbecomesmethod-specific.Section10coversthe
REGISTERrequest,Section11coverstheOPTIONSrequest,Section13
coverstheINVITErequest,andSection15coverstheBYErequest.
8.2.6GeneratingtheResponse
WhenaUASwishestoconstructaresponsetoarequest,itfollows
thegeneralproceduresdetailedinthefollowingsubsections.
Additionalbehaviorsspecifictotheresponsecodeinquestion,which
arenotdetailedinthissection,mayalsoberequired.
Onceallproceduresassociatedwiththecreationofaresponsehave
beencompleted,theUAShandstheresponsebacktotheserver
transactionfromwhichitreceivedtherequest.
8.2.6.1SendingaProvisionalResponse
Onelargelynon-method-specificguidelineforthegenerationof
responsesisthatUASsSHOULDNOTissueaprovisionalresponsefora
non-INVITErequest.Rather,UASsSHOULDgenerateafinalresponseto
anon-INVITErequestassoonaspossible.
Rosenberg,et.al.StandardsTrack[Page49]
RFC3261SIP:SessionInitiationProtocolJune2002
Whena100(Trying)responseisgenerated,anyTimestampheaderfield
presentintherequestMUSTbecopiedintothis100(Trying)
response.Ifthereisadelayingeneratingtheresponse,theUAS
SHOULDaddadelayvalueintotheTimestampvalueintheresponse.
ThisvalueMUSTcontainthedifferencebetweenthetimeofsendingof
theresponseandreceiptoftherequest,measuredinseconds.
8.2.6.2HeadersandTags
TheFromfieldoftheresponseMUSTequaltheFromheaderfieldof
therequest.TheCall-IDheaderfieldoftheresponseMUSTequalthe
Call-IDheaderfieldoftherequest.TheCSeqheaderfieldofthe
responseMUSTequaltheCSeqfieldoftherequest.TheViaheader
fieldvaluesintheresponseMUSTequaltheViaheaderfieldvalues
intherequestandMUSTmaintainthesameordering.
IfarequestcontainedaTotagintherequest,theToheaderfield
intheresponseMUSTequalthatoftherequest.However,iftheTo
headerfieldintherequestdidnotcontainatag,theURIintheTo
headerfieldintheresponseMUSTequaltheURIintheToheader
field;additionally,theUASMUSTaddatagtotheToheaderfieldin
theresponse(withtheexceptionofthe100(Trying)response,in
whichatagMAYbepresent).ThisservestoidentifytheUASthatis
responding,possiblyresultinginacomponentofadialogID.The
sametagMUSTbeusedforallresponsestothatrequest,bothfinal
andprovisional(againexceptingthe100(Trying)).Proceduresfor
thegenerationoftagsaredefinedinSection19.3.
8.2.7StatelessUASBehavior
AstatelessUASisaUASthatdoesnotmaintaintransactionstate.
Itrepliestorequestsnormally,butdiscardsanystatethatwould
ordinarilyberetainedbyaUASafteraresponsehasbeensent.Ifa
statelessUASreceivesaretransmissionofarequest,itregenerates
theresponseandresendsit,justasifitwerereplyingtothefirst
instanceoftherequest.AUAScannotbestatelessunlesstherequest
processingforthatmethodwouldalwaysresultinthesameresponse
iftherequestsareidentical.Thisrulesoutstatelessregistrars,
forexample.StatelessUASsdonotuseatransactionlayer;they
receiverequestsdirectlyfromthetransportlayerandsendresponses
directlytothetransportlayer.
ThestatelessUASroleisneededprimarilytohandleunauthenticated
requestsforwhichachallengeresponseisissued.If
unauthenticatedrequestswerehandledstatefully,thenmalicious
floodsofunauthenticatedrequestscouldcreatemassiveamountsof
Rosenberg,et.al.StandardsTrack[Page50]
RFC3261SIP:SessionInitiationProtocolJune2002
transactionstatethatmightsloworcompletelyhaltcallprocessing
inaUAS,effectivelycreatingadenialofservicecondition;for
moreinformationseeSection26.1.5.
ThemostimportantbehaviorsofastatelessUASarethefollowing:
oAstatelessUASMUSTNOTsendprovisional(1xx)responses.
oAstatelessUASMUSTNOTretransmitresponses.
oAstatelessUASMUSTignoreACKrequests.
oAstatelessUASMUSTignoreCANCELrequests.
oToheadertagsMUSTbegeneratedforresponsesinastateless
manner-inamannerthatwillgeneratethesametagforthe
samerequestconsistently.Forinformationontagconstruction
seeSection19.3.
Inallotherrespects,astatelessUASbehavesinthesamemanneras
astatefulUAS.AUAScanoperateineitherastatefulorstateless
modeforeachnewrequest.
8.3RedirectServers
Insomearchitecturesitmaybedesirabletoreducetheprocessing
loadonproxyserversthatareresponsibleforroutingrequests,and
improvesignalingpathrobustness,byrelyingonredirection.
Redirectionallowsserverstopushroutinginformationforarequest
backinaresponsetotheclient,therebytakingthemselvesoutof
theloopoffurthermessagingforthistransactionwhilestillaiding
inlocatingthetargetoftherequest.Whentheoriginatorofthe
requestreceivestheredirection,itwillsendanewrequestbasedon
theURI(s)ithasreceived.BypropagatingURIsfromthecoreofthe
networktoitsedges,redirectionallowsforconsiderablenetwork
scalability.
Aredirectserverislogicallyconstitutedofaservertransaction
layerandatransactionuserthathasaccesstoalocationserviceof
somekind(seeSection10formoreonregistrarsandlocation
services).Thislocationserviceiseffectivelyadatabase
containingmappingsbetweenasingleURIandasetofoneormore
alternativelocationsatwhichthetargetofthatURIcanbefound.
AredirectserverdoesnotissueanySIPrequestsofitsown.After
receivingarequestotherthanCANCEL,theservereitherrefusesthe
requestorgathersthelistofalternativelocationsfromthe
Rosenberg,et.al.StandardsTrack[Page51]
RFC3261SIP:SessionInitiationProtocolJune2002
locationserviceandreturnsafinalresponseofclass3xx.For
well-formedCANCELrequests,itSHOULDreturna2xxresponse.This
responseendstheSIPtransaction.Theredirectservermaintains
transactionstateforanentireSIPtransaction.Itisthe
responsibilityofclientstodetectforwardingloopsbetweenredirect
servers.
Whenaredirectserverreturnsa3xxresponsetoarequest,it
populatesthelistof(oneormore)alternativelocationsintothe
Contactheaderfield.An"expires"parametertotheContactheader
fieldvaluesmayalsobesuppliedtoindicatethelifetimeofthe
Contactdata.
TheContactheaderfieldcontainsURIsgivingthenewlocationsor
usernamestotry,ormaysimplyspecifyadditionaltransport
parameters.A301(MovedPermanently)or302(MovedTemporarily)
responsemayalsogivethesamelocationandusernamethatwas
targetedbytheinitialrequestbutspecifyadditionaltransport
parameterssuchasadifferentserverormulticastaddresstotry,or
achangeofSIPtransportfromUDPtoTCPorviceversa.
However,redirectserversMUSTNOTredirectarequesttoaURIequal
totheoneintheRequest-URI;instead,providedthattheURIdoes
notpointtoitself,theserverMAYproxytherequesttothe
destinationURI,orMAYrejectitwitha404.
Ifaclientisusinganoutboundproxy,andthatproxyactually
redirectsrequests,apotentialarisesforinfiniteredirection
loops.
NotethataContactheaderfieldvalueMAYalsorefertoadifferent
resourcethantheoneoriginallycalled.Forexample,aSIPcall
connectedtoPSTNgatewaymayneedtodeliveraspecialinformational
announcementsuchas"Thenumberyouhavedialedhasbeenchanged."
AContactresponseheaderfieldcancontainanysuitableURI
indicatingwherethecalledpartycanbereached,notlimitedtoSIP
URIs.Forexample,itcouldcontainURIsforphones,fax,orirc(if
theyweredefined)oramailto:(RFC2368[32])URL.Section26.4.4
discussesimplicationsandlimitationsofredirectingaSIPSURItoa
non-SIPSURI.
The"expires"parameterofaContactheaderfieldvalueindicateshow
longtheURIisvalid.Thevalueoftheparameterisanumber
indicatingseconds.Ifthisparameterisnotprovided,thevalueof
theExpiresheaderfielddetermineshowlongtheURIisvalid.
MalformedvaluesSHOULDbetreatedasequivalentto3600.
Rosenberg,et.al.StandardsTrack[Page52]
RFC3261SIP:SessionInitiationProtocolJune2002
ThisprovidesamodestlevelofbackwardscompatibilitywithRFC
2543,whichallowedabsolutetimesinthisheaderfield.Ifan
absolutetimeisreceived,itwillbetreatedasmalformed,and
thendefaultto3600.
RedirectserversMUSTignorefeaturesthatarenotunderstood
(includingunrecognizedheaderfields,anyunknownoptiontagsin
Require,orevenmethodnames)andproceedwiththeredirectionof
therequestinquestion.
9CancelingaRequest
TheprevioussectionhasdiscussedgeneralUAbehaviorforgenerating
requestsandprocessingresponsesforrequestsofallmethods.In
thissection,wediscussageneralpurposemethod,calledCANCEL.
TheCANCELrequest,asthenameimplies,isusedtocancelaprevious
requestsentbyaclient.Specifically,itaskstheUAStocease
processingtherequestandtogenerateanerrorresponsetothat
request.CANCELhasnoeffectonarequesttowhichaUAShas
alreadygivenafinalresponse.Becauseofthis,itismostuseful
toCANCELrequeststowhichitcantakeaserverlongtimeto
respond.Forthisreason,CANCELisbestforINVITErequests,which
cantakealongtimetogeneratearesponse.Inthatusage,aUAS
thatreceivesaCANCELrequestforanINVITE,buthasnotyetsenta
finalresponse,would"stopringing",andthenrespondtotheINVITE
withaspecificerrorresponse(a487).
CANCELrequestscanbeconstructedandsentbybothproxiesanduser
agentclients.Section15discussesunderwhatconditionsaUAC
wouldCANCELanINVITErequest,andSection16.10discussesproxy
usageofCANCEL.
AstatefulproxyrespondstoaCANCEL,ratherthansimplyforwarding
aresponseitwouldreceivefromadownstreamelement.Forthat
reason,CANCELisreferredtoasa"hop-by-hop"request,sinceitis
respondedtoateachstatefulproxyhop.
9.1ClientBehavior
ACANCELrequestSHOULDNOTbesenttocancelarequestotherthan
INVITE.
SincerequestsotherthanINVITEarerespondedtoimmediately,
sendingaCANCELforanon-INVITErequestwouldalwayscreatea
racecondition.
Rosenberg,et.al.StandardsTrack[Page53]
RFC3261SIP:SessionInitiationProtocolJune2002
ThefollowingproceduresareusedtoconstructaCANCELrequest.The
Request-URI,Call-ID,To,thenumericpartofCSeq,andFromheader
fieldsintheCANCELrequestMUSTbeidenticaltothoseinthe
requestbeingcancelled,includingtags.ACANCELconstructedbya
clientMUSThaveonlyasingleViaheaderfieldvaluematchingthe
topViavalueintherequestbeingcancelled.Usingthesamevalues
fortheseheaderfieldsallowstheCANCELtobematchedwiththe
requestitcancels(Section9.2indicateshowsuchmatchingoccurs).
However,themethodpartoftheCSeqheaderfieldMUSThaveavalue
ofCANCEL.Thisallowsittobeidentifiedandprocessedasa
transactioninitsownright(SeeSection17).
IftherequestbeingcancelledcontainsaRouteheaderfield,the
CANCELrequestMUSTincludethatRouteheaderfield'svalues.
ThisisneededsothatstatelessproxiesareabletorouteCANCEL
requestsproperly.
TheCANCELrequestMUSTNOTcontainanyRequireorProxy-Require
headerfields.
OncetheCANCELisconstructed,theclientSHOULDcheckwhetherit
hasreceivedanyresponse(provisionalorfinal)fortherequest
beingcancelled(hereinreferredtoasthe"originalrequest").
Ifnoprovisionalresponsehasbeenreceived,theCANCELrequestMUST
NOTbesent;rather,theclientMUSTwaitforthearrivalofa
provisionalresponsebeforesendingtherequest.Iftheoriginal
requesthasgeneratedafinalresponse,theCANCELSHOULDNOTbe
sent,asitisaneffectiveno-op,sinceCANCELhasnoeffecton
requeststhathavealreadygeneratedafinalresponse.Whenthe
clientdecidestosendtheCANCEL,itcreatesaclienttransaction
fortheCANCELandpassesittheCANCELrequestalongwiththe
destinationaddress,port,andtransport.Thedestinationaddress,
port,andtransportfortheCANCELMUSTbeidenticaltothoseusedto
sendtheoriginalrequest.
IfitwasallowedtosendtheCANCELbeforereceivingaresponse
forthepreviousrequest,theservercouldreceivetheCANCEL
beforetheoriginalrequest.
Notethatboththetransactioncorrespondingtotheoriginalrequest
andtheCANCELtransactionwillcompleteindependently.However,a
UACcancelingarequestcannotrelyonreceivinga487(Request
Terminated)responsefortheoriginalrequest,asanRFC2543-
compliantUASwillnotgeneratesucharesponse.Ifthereisno
finalresponsefortheoriginalrequestin64*T1seconds(T1is
Rosenberg,et.al.StandardsTrack[Page54]
RFC3261SIP:SessionInitiationProtocolJune2002
definedinSection17.1.1.1),theclientSHOULDthenconsiderthe
originaltransactioncancelledandSHOULDdestroytheclient
transactionhandlingtheoriginalrequest.
9.2ServerBehavior
TheCANCELmethodrequeststhattheTUattheserversidecancela
pendingtransaction.TheTUdeterminesthetransactiontobe
cancelledbytakingtheCANCELrequest,andthenassumingthatthe
requestmethodisanythingbutCANCELorACKandapplyingthe
transactionmatchingproceduresofSection17.2.3.Thematching
transactionistheonetobecancelled.
TheprocessingofaCANCELrequestataserverdependsonthetypeof
server.Astatelessproxywillforwardit,astatefulproxymight
respondtoitandgeneratesomeCANCELrequestsofitsown,andaUAS
willrespondtoit.SeeSection16.10forproxytreatmentofCANCEL.
AUASfirstprocessestheCANCELrequestaccordingtothegeneralUAS
processingdescribedinSection8.2.However,sinceCANCELrequests
arehop-by-hopandcannotberesubmitted,theycannotbechallenged
bytheserverinordertogetpropercredentialsinanAuthorization
headerfield.NotealsothatCANCELrequestsdonotcontaina
Requireheaderfield.
IftheUASdidnotfindamatchingtransactionfortheCANCEL
accordingtotheprocedureabove,itSHOULDrespondtotheCANCEL
witha481(CallLeg/TransactionDoesNotExist).Ifthetransaction
fortheoriginalrequeststillexists,thebehavioroftheUASon
receivingaCANCELrequestdependsonwhetherithasalreadysenta
finalresponsefortheoriginalrequest.Ifithas,theCANCEL
requesthasnoeffectontheprocessingoftheoriginalrequest,no
effectonanysessionstate,andnoeffectontheresponsesgenerated
fortheoriginalrequest.IftheUAShasnotissuedafinalresponse
fortheoriginalrequest,itsbehaviordependsonthemethodofthe
originalrequest.IftheoriginalrequestwasanINVITE,theUAS
SHOULDimmediatelyrespondtotheINVITEwitha487(Request
Terminated).ACANCELrequesthasnoimpactontheprocessingof
transactionswithanyothermethoddefinedinthisspecification.
Regardlessofthemethodoftheoriginalrequest,aslongasthe
CANCELmatchedanexistingtransaction,theUASanswerstheCANCEL
requestitselfwitha200(OK)response.Thisresponseis
constructedfollowingtheproceduresdescribedinSection8.2.6
notingthattheTotagoftheresponsetotheCANCELandtheTotag
intheresponsetotheoriginalrequestSHOULDbethesame.The
responsetoCANCELispassedtotheservertransactionfor
transmission.
Rosenberg,et.al.StandardsTrack[Page55]
RFC3261SIP:SessionInitiationProtocolJune2002
10Registrations
10.1Overview
SIPoffersadiscoverycapability.Ifauserwantstoinitiatea
sessionwithanotheruser,SIPmustdiscoverthecurrenthost(s)at
whichthedestinationuserisreachable.Thisdiscoveryprocessis
frequentlyaccomplishedbySIPnetworkelementssuchasproxyservers
andredirectserverswhichareresponsibleforreceivingarequest,
determiningwheretosenditbasedonknowledgeofthelocationof
theuser,andthensendingitthere.Todothis,SIPnetwork
elementsconsultanabstractserviceknownasalocationservice,
whichprovidesaddressbindingsforaparticulardomain.These
addressbindingsmapanincomingSIPorSIPSURI,sip:[email protected],
forexample,tooneormoreURIsthataresomehow"closer"tothe
desireduser,sip:[email protected],forexample.
Ultimately,aproxywillconsultalocationservicethatmapsa
receivedURItotheuseragent(s)atwhichthedesiredrecipientis
currentlyresiding.
Registrationcreatesbindingsinalocationserviceforaparticular
domainthatassociatesanaddress-of-recordURIwithoneormore
contactaddresses.Thus,whenaproxyforthatdomainreceivesa
requestwhoseRequest-URImatchestheaddress-of-record,theproxy
willforwardtherequesttothecontactaddressesregisteredtothat
address-of-record.Generally,itonlymakessensetoregisteran
address-of-recordatadomain'slocationservicewhenrequestsfor
thataddress-of-recordwouldberoutedtothatdomain.Inmost
cases,thismeansthatthedomainoftheregistrationwillneedto
matchthedomainintheURIoftheaddress-of-record.
Therearemanywaysbywhichthecontentsofthelocationservicecan
beestablished.Onewayisadministratively.Intheaboveexample,
Bobisknowntobeamemberoftheengineeringdepartmentthrough
accesstoacorporatedatabase.However,SIPprovidesamechanism
foraUAtocreateabindingexplicitly.Thismechanismisknownas
registration.
RegistrationentailssendingaREGISTERrequesttoaspecialtypeof
UASknownasaregistrar.Aregistraractsasthefrontendtothe
locationserviceforadomain,readingandwritingmappingsbasedon
thecontentsofREGISTERrequests.Thislocationserviceisthen
typicallyconsultedbyaproxyserverthatisresponsibleforrouting
requestsforthatdomain.
Anillustrationoftheoverallregistrationprocessisgivenin
Figure2.Notethattheregistrarandproxyserverarelogicalroles
thatcanbeplayedbyasingledeviceinanetwork;forpurposesof
Rosenberg,et.al.StandardsTrack[Page56]
RFC3261SIP:SessionInitiationProtocolJune2002
claritythetwoareseparatedinthisillustration.Alsonotethat
UAsmaysendrequeststhroughaproxyserverinordertoreacha
registrarifthetwoareseparateelements.
SIPdoesnotmandateaparticularmechanismforimplementingthe
locationservice.Theonlyrequirementisthataregistrarforsome
domainMUSTbeabletoreadandwritedatatothelocationservice,
andaproxyoraredirectserverforthatdomainMUSTbecapableof
readingthatsamedata.AregistrarMAYbeco-locatedwitha
particularSIPproxyserverforthesamedomain.
10.2ConstructingtheREGISTERRequest
REGISTERrequestsadd,remove,andquerybindings.AREGISTER
requestcanaddanewbindingbetweenanaddress-of-recordandoneor
morecontactaddresses.Registrationonbehalfofaparticular
address-of-recordcanbeperformedbyasuitablyauthorizedthird
party.Aclientcanalsoremovepreviousbindingsorqueryto
determinewhichbindingsarecurrentlyinplaceforanaddress-of-
record.
Exceptasnoted,theconstructionoftheREGISTERrequestandthe
behaviorofclientssendingaREGISTERrequestisidenticaltothe
generalUACbehaviordescribedinSection8.1andSection17.1.
AREGISTERrequestdoesnotestablishadialog.AUACMAYincludea
RouteheaderfieldinaREGISTERrequestbasedonapre-existing
routesetasdescribedinSection8.1.TheRecord-Routeheaderfield
hasnomeaninginREGISTERrequestsorresponses,andMUSTbeignored
ifpresent.Inparticular,theUACMUSTNOTcreateanewrouteset
basedonthepresenceorabsenceofaRecord-Routeheaderfieldin
anyresponsetoaREGISTERrequest.
Thefollowingheaderfields,exceptContact,MUSTbeincludedina
REGISTERrequest.AContactheaderfieldMAYbeincluded:
Request-URI:TheRequest-URInamesthedomainofthelocation
serviceforwhichtheregistrationismeant(forexample,
"sip:chicago.com").The"userinfo"and"@"componentsofthe
SIPURIMUSTNOTbepresent.
To:TheToheaderfieldcontainstheaddressofrecordwhose
registrationistobecreated,queried,ormodified.TheTo
headerfieldandtheRequest-URIfieldtypicallydiffer,as
theformercontainsausername.Thisaddress-of-recordMUST
beaSIPURIorSIPSURI.
Rosenberg,et.al.StandardsTrack[Page57]
RFC3261SIP:SessionInitiationProtocolJune2002
From:TheFromheaderfieldcontainstheaddress-of-recordofthe
personresponsiblefortheregistration.Thevalueisthe
sameastheToheaderfieldunlesstherequestisathird-
partyregistration.
Call-ID:AllregistrationsfromaUACSHOULDusethesameCall-ID
headerfieldvalueforregistrationssenttoaparticular
registrar.
IfthesameclientweretousedifferentCall-IDvalues,a
registrarcouldnotdetectwhetheradelayedREGISTERrequest
mighthavearrivedoutoforder.
CSeq:TheCSeqvalueguaranteesproperorderingofREGISTER
requests.AUAMUSTincrementtheCSeqvaluebyoneforeach
REGISTERrequestwiththesameCall-ID.
Contact:REGISTERrequestsMAYcontainaContactheaderfieldwith
zeroormorevaluescontainingaddressbindings.
UAsMUSTNOTsendanewregistration(thatis,containingnewContact
headerfieldvalues,asopposedtoaretransmission)untiltheyhave
receivedafinalresponsefromtheregistrarforthepreviousoneor
thepreviousREGISTERrequesthastimedout.
Rosenberg,et.al.StandardsTrack[Page58]
RFC3261SIP:SessionInitiationProtocolJune2002
bob
+----+
|UA|
||
+----+
|
|3)INVITE
|[email protected]
chicago.com+--------+V
+---------+2)Store|Location|4)Query+-----+
|Registrar|=======>|Service|<=======|Proxy|sip.chicago.com
+---------++--------+=======>+-----+
A5)Resp|
||
||
1)REGISTER||
||
+----+|
|UA|
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:63104OPTIONS
Contact:
Accept:application/sdp
Content-Length:0
Rosenberg,et.al.StandardsTrack[Page67]
RFC3261SIP:SessionInitiationProtocolJune2002
11.2ProcessingofOPTIONSRequest
TheresponsetoanOPTIONSisconstructedusingthestandardrules
foraSIPresponseasdiscussedinSection8.2.6.Theresponsecode
chosenMUSTbethesamethatwouldhavebeenchosenhadtherequest
beenanINVITE.Thatis,a200(OK)wouldbereturnediftheUASis
readytoacceptacall,a486(BusyHere)wouldbereturnedifthe
UASisbusy,etc.ThisallowsanOPTIONSrequesttobeusedto
determinethebasicstateofaUAS,whichcanbeanindicationof
whethertheUASwillacceptanINVITErequest.
AnOPTIONSrequestreceivedwithinadialoggeneratesa200(OK)
responsethatisidenticaltooneconstructedoutsideadialogand
doesnothaveanyimpactonthedialog.
ThisuseofOPTIONShaslimitationsduetothedifferencesinproxy
handlingofOPTIONSandINVITErequests.WhileaforkedINVITEcan
resultinmultiple200(OK)responsesbeingreturned,aforked
OPTIONSwillonlyresultinasingle200(OK)response,sinceitis
treatedbyproxiesusingthenon-INVITEhandling.SeeSection16.7
forthenormativedetails.
IftheresponsetoanOPTIONSisgeneratedbyaproxyserver,the
proxyreturnsa200(OK),listingthecapabilitiesoftheserver.
Theresponsedoesnotcontainamessagebody.
Allow,Accept,Accept-Encoding,Accept-Language,andSupportedheader
fieldsSHOULDbepresentina200(OK)responsetoanOPTIONS
request.Iftheresponseisgeneratedbyaproxy,theAllowheader
fieldSHOULDbeomittedasitisambiguoussinceaproxyismethod
agnostic.ContactheaderfieldsMAYbepresentina200(OK)
responseandhavethesamesemanticsasina3xxresponse.Thatis,
theymaylistasetofalternativenamesandmethodsofreachingthe
user.AWarningheaderfieldMAYbepresent.
AmessagebodyMAYbesent,thetypeofwhichisdeterminedbythe
AcceptheaderfieldintheOPTIONSrequest(application/sdpisthe
defaultiftheAcceptheaderfieldisnotpresent).Ifthetypes
includeonethatcandescribemediacapabilities,theUASSHOULD
includeabodyintheresponseforthatpurpose.Detailsonthe
constructionofsuchabodyinthecaseofapplication/sdpare
describedin[13].
Rosenberg,et.al.StandardsTrack[Page68]
RFC3261SIP:SessionInitiationProtocolJune2002
ExampleOPTIONSresponsegeneratedbyaUAS(correspondingtothe
requestinSection11.1):
SIP/2.0200OK
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To:;tag=93810874
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:63104OPTIONS
Contact:
Contact:
Allow:INVITE,ACK,CANCEL,OPTIONS,BYE
Accept:application/sdp
Accept-Encoding:gzip
Accept-Language:en
Supported:foo
Content-Type:application/sdp
Content-Length:274
(SDPnotshown)
12Dialogs
Akeyconceptforauseragentisthatofadialog.Adialog
representsapeer-to-peerSIPrelationshipbetweentwouseragents
thatpersistsforsometime.Thedialogfacilitatessequencingof
messagesbetweentheuseragentsandproperroutingofrequests
betweenbothofthem.Thedialogrepresentsacontextinwhichto
interpretSIPmessages.Section8discussedmethodindependentUA
processingforrequestsandresponsesoutsideofadialog.This
sectiondiscusseshowthoserequestsandresponsesareusedto
constructadialog,andthenhowsubsequentrequestsandresponses
aresentwithinadialog.
AdialogisidentifiedateachUAwithadialogID,whichconsistsof
aCall-IDvalue,alocaltagandaremotetag.ThedialogIDateach
UAinvolvedinthedialogisnotthesame.Specifically,thelocal
tagatoneUAisidenticaltotheremotetagatthepeerUA.The
tagsareopaquetokensthatfacilitatethegenerationofunique
dialogIDs.
AdialogIDisalsoassociatedwithallresponsesandwithany
requestthatcontainsatagintheTofield.Therulesforcomputing
thedialogIDofamessagedependonwhethertheSIPelementisaUAC
orUAS.ForaUAC,theCall-IDvalueofthedialogIDissettothe
Call-IDofthemessage,theremotetagissettothetagintheTo
fieldofthemessage,andthelocaltagissettothetagintheFrom
Rosenberg,et.al.StandardsTrack[Page69]
RFC3261SIP:SessionInitiationProtocolJune2002
fieldofthemessage(theserulesapplytobothrequestsand
responses).AsonewouldexpectforaUAS,theCall-IDvalueofthe
dialogIDissettotheCall-IDofthemessage,theremotetagisset
tothetagintheFromfieldofthemessage,andthelocaltagisset
tothetagintheTofieldofthemessage.
Adialogcontainscertainpiecesofstateneededforfurthermessage
transmissionswithinthedialog.Thisstateconsistsofthedialog
ID,alocalsequencenumber(usedtoorderrequestsfromtheUAto
itspeer),aremotesequencenumber(usedtoorderrequestsfromits
peertotheUA),alocalURI,aremoteURI,remotetarget,aboolean
flagcalled"secure",andarouteset,whichisanorderedlistof
URIs.Theroutesetisthelistofserversthatneedtobetraversed
tosendarequesttothepeer.Adialogcanalsobeinthe"early"
state,whichoccurswhenitiscreatedwithaprovisionalresponse,
andthentransitiontothe"confirmed"statewhena2xxfinal
responsearrives.Forotherresponses,orifnoresponsearrivesat
allonthatdialog,theearlydialogterminates.
12.1CreationofaDialog
Dialogsarecreatedthroughthegenerationofnon-failureresponses
torequestswithspecificmethods.Withinthisspecification,only
2xxand101-199responseswithaTotag,wheretherequestwas
INVITE,willestablishadialog.Adialogestablishedbyanon-final
responsetoarequestisinthe"early"stateanditiscalledan
earlydialog.ExtensionsMAYdefineothermeansforcreating
dialogs.Section13givesmoredetailsthatarespecifictothe
INVITEmethod.Here,wedescribetheprocessforcreationofdialog
statethatisnotdependentonthemethod.
UAsMUSTassignvaluestothedialogIDcomponentsasdescribed
below.
12.1.1UASbehavior
WhenaUASrespondstoarequestwitharesponsethatestablishesa
dialog(suchasa2xxtoINVITE),theUASMUSTcopyallRecord-Route
headerfieldvaluesfromtherequestintotheresponse(includingthe
URIs,URIparameters,andanyRecord-Routeheaderfieldparameters,
whethertheyareknownorunknowntotheUAS)andMUSTmaintainthe
orderofthosevalues.TheUASMUSTaddaContactheaderfieldto
theresponse.TheContactheaderfieldcontainsanaddresswherethe
UASwouldliketobecontactedforsubsequentrequestsinthedialog
(whichincludestheACKfora2xxresponseinthecaseofanINVITE).
Generally,thehostportionofthisURIistheIPaddressorFQDNof
thehost.TheURIprovidedintheContactheaderfieldMUSTbeaSIP
orSIPSURI.Iftherequestthatinitiatedthedialogcontaineda
Rosenberg,et.al.StandardsTrack[Page70]
RFC3261SIP:SessionInitiationProtocolJune2002
SIPSURIintheRequest-URIorinthetopRecord-Routeheaderfield
value,iftherewasany,ortheContactheaderfieldiftherewasno
Record-Routeheaderfield,theContactheaderfieldintheresponse
MUSTbeaSIPSURI.TheURISHOULDhaveglobalscope(thatis,the
sameURIcanbeusedinmessagesoutsidethisdialog).Thesameway,
thescopeoftheURIintheContactheaderfieldoftheINVITEisnot
limitedtothisdialogeither.Itcanthereforebeusedinmessages
totheUACevenoutsidethisdialog.
TheUASthenconstructsthestateofthedialog.ThisstateMUSTbe
maintainedforthedurationofthedialog.
IftherequestarrivedoverTLS,andtheRequest-URIcontainedaSIPS
URI,the"secure"flagissettoTRUE.
TheroutesetMUSTbesettothelistofURIsintheRecord-Route
headerfieldfromtherequest,takeninorderandpreservingallURI
parameters.IfnoRecord-Routeheaderfieldispresentinthe
request,theroutesetMUSTbesettotheemptyset.Thisrouteset,
evenifempty,overridesanypre-existingroutesetforfuture
requestsinthisdialog.TheremotetargetMUSTbesettotheURI
fromtheContactheaderfieldoftherequest.
TheremotesequencenumberMUSTbesettothevalueofthesequence
numberintheCSeqheaderfieldoftherequest.Thelocalsequence
numberMUSTbeempty.ThecallidentifiercomponentofthedialogID
MUSTbesettothevalueoftheCall-IDintherequest.Thelocal
tagcomponentofthedialogIDMUSTbesettothetagintheTofield
intheresponsetotherequest(whichalwaysincludesatag),andthe
remotetagcomponentofthedialogIDMUSTbesettothetagfromthe
Fromfieldintherequest.AUASMUSTbepreparedtoreceivea
requestwithoutatagintheFromfield,inwhichcasethetagis
consideredtohaveavalueofnull.
ThisistomaintainbackwardscompatibilitywithRFC2543,which
didnotmandateFromtags.
TheremoteURIMUSTbesettotheURIintheFromfield,andthe
localURIMUSTbesettotheURIintheTofield.
12.1.2UACBehavior
WhenaUACsendsarequestthatcanestablishadialog(suchasan
INVITE)itMUSTprovideaSIPorSIPSURIwithglobalscope(i.e.,
thesameSIPURIcanbeusedinmessagesoutsidethisdialog)inthe
Contactheaderfieldoftherequest.IftherequesthasaRequest-
URIoratopmostRouteheaderfieldvaluewithaSIPSURI,the
ContactheaderfieldMUSTcontainaSIPSURI.
Rosenberg,et.al.StandardsTrack[Page71]
RFC3261SIP:SessionInitiationProtocolJune2002
WhenaUACreceivesaresponsethatestablishesadialog,it
constructsthestateofthedialog.ThisstateMUSTbemaintained
forthedurationofthedialog.
IftherequestwassentoverTLS,andtheRequest-URIcontaineda
SIPSURI,the"secure"flagissettoTRUE.
TheroutesetMUSTbesettothelistofURIsintheRecord-Route
headerfieldfromtheresponse,takeninreverseorderandpreserving
allURIparameters.IfnoRecord-Routeheaderfieldispresentin
theresponse,theroutesetMUSTbesettotheemptyset.Thisroute
set,evenifempty,overridesanypre-existingroutesetforfuture
requestsinthisdialog.TheremotetargetMUSTbesettotheURI
fromtheContactheaderfieldoftheresponse.
ThelocalsequencenumberMUSTbesettothevalueofthesequence
numberintheCSeqheaderfieldoftherequest.Theremotesequence
numberMUSTbeempty(itisestablishedwhentheremoteUAsendsa
requestwithinthedialog).Thecallidentifiercomponentofthe
dialogIDMUSTbesettothevalueoftheCall-IDintherequest.
ThelocaltagcomponentofthedialogIDMUSTbesettothetagin
theFromfieldintherequest,andtheremotetagcomponentofthe
dialogIDMUSTbesettothetagintheTofieldoftheresponse.A
UACMUSTbepreparedtoreceivearesponsewithoutatagintheTo
field,inwhichcasethetagisconsideredtohaveavalueofnull.
ThisistomaintainbackwardscompatibilitywithRFC2543,which
didnotmandateTotags.
TheremoteURIMUSTbesettotheURIintheTofield,andthelocal
URIMUSTbesettotheURIintheFromfield.
12.2RequestswithinaDialog
OnceadialoghasbeenestablishedbetweentwoUAs,eitherofthem
MAYinitiatenewtransactionsasneededwithinthedialog.TheUA
sendingtherequestwilltaketheUACroleforthetransaction.The
UAreceivingtherequestwilltaketheUASrole.Notethatthesemay
bedifferentrolesthantheUAsheldduringthetransactionthat
establishedthedialog.
RequestswithinadialogMAYcontainRecord-RouteandContactheader
fields.However,theserequestsdonotcausethedialog'srouteset
tobemodified,althoughtheymaymodifytheremotetargetURI.
Specifically,requeststhatarenottargetrefreshrequestsdonot
modifythedialog'sremotetargetURI,andrequeststhataretarget
refreshrequestsdo.Fordialogsthathavebeenestablishedwithan
Rosenberg,et.al.StandardsTrack[Page72]
RFC3261SIP:SessionInitiationProtocolJune2002
INVITE,theonlytargetrefreshrequestdefinedisre-INVITE(see
Section14).Otherextensionsmaydefinedifferenttargetrefresh
requestsfordialogsestablishedinotherways.
NotethatanACKisNOTatargetrefreshrequest.
Targetrefreshrequestsonlyupdatethedialog'sremotetargetURI,
andnottheroutesetformedfromtheRecord-Route.Updatingthe
latterwouldintroduceseverebackwardscompatibilityproblemswith
RFC2543-compliantsystems.
12.2.1UACBehavior
12.2.1.1GeneratingtheRequest
Arequestwithinadialogisconstructedbyusingmanyofthe
componentsofthestatestoredaspartofthedialog.
TheURIintheTofieldoftherequestMUSTbesettotheremoteURI
fromthedialogstate.ThetagintheToheaderfieldoftherequest
MUSTbesettotheremotetagofthedialogID.TheFromURIofthe
requestMUSTbesettothelocalURIfromthedialogstate.Thetag
intheFromheaderfieldoftherequestMUSTbesettothelocaltag
ofthedialogID.Ifthevalueoftheremoteorlocaltagsisnull,
thetagparameterMUSTbeomittedfromtheToorFromheaderfields,
respectively.
UsageoftheURIfromtheToandFromfieldsintheoriginal
requestwithinsubsequentrequestsisdoneforbackwards
compatibilitywithRFC2543,whichusedtheURIfordialog
identification.Inthisspecification,onlythetagsareusedfor
dialogidentification.Itisexpectedthatmandatoryreflection
oftheoriginalToandFromURIinmid-dialogrequestswillbe
deprecatedinasubsequentrevisionofthisspecification.
TheCall-IDoftherequestMUSTbesettotheCall-IDofthedialog.
RequestswithinadialogMUSTcontainstrictlymonotonically
increasingandcontiguousCSeqsequencenumbers(increasing-by-one)
ineachdirection(exceptingACKandCANCELofcourse,whosenumbers
equaltherequestsbeingacknowledgedorcancelled).Therefore,if
thelocalsequencenumberisnotempty,thevalueofthelocal
sequencenumberMUSTbeincrementedbyone,andthisvalueMUSTbe
placedintotheCSeqheaderfield.Ifthelocalsequencenumberis
empty,aninitialvalueMUSTbechosenusingtheguidelinesof
Section8.1.1.5.ThemethodfieldintheCSeqheaderfieldvalue
MUSTmatchthemethodoftherequest.
Rosenberg,et.al.StandardsTrack[Page73]
RFC3261SIP:SessionInitiationProtocolJune2002
Withalengthof32bits,aclientcouldgenerate,withinasingle
call,onerequestasecondforabout136yearsbeforeneedingto
wraparound.Theinitialvalueofthesequencenumberischosen
sothatsubsequentrequestswithinthesamecallwillnotwrap
around.Anon-zeroinitialvalueallowsclientstouseatime-
basedinitialsequencenumber.Aclientcould,forexample,
choosethe31mostsignificantbitsofa32-bitsecondclockasan
initialsequencenumber.
TheUACusestheremotetargetandroutesettobuildtheRequest-URI
andRouteheaderfieldoftherequest.
Iftheroutesetisempty,theUACMUSTplacetheremotetargetURI
intotheRequest-URI.TheUACMUSTNOTaddaRouteheaderfieldto
therequest.
Iftheroutesetisnotempty,andthefirstURIintherouteset
containsthelrparameter(seeSection19.1.1),theUACMUSTplace
theremotetargetURIintotheRequest-URIandMUSTincludeaRoute
headerfieldcontainingtheroutesetvaluesinorder,includingall
parameters.
Iftheroutesetisnotempty,anditsfirstURIdoesnotcontainthe
lrparameter,theUACMUSTplacethefirstURIfromtherouteset
intotheRequest-URI,strippinganyparametersthatarenotallowed
inaRequest-URI.TheUACMUSTaddaRouteheaderfieldcontaining
theremainderoftheroutesetvaluesinorder,includingall
parameters.TheUACMUSTthenplacetheremotetargetURIintothe
Routeheaderfieldasthelastvalue.
Forexample,iftheremotetargetissip:user@remoteuaandtheroute
setcontains:
,,,
TherequestwillbeformedwiththefollowingRequest-URIandRoute
headerfield:
METHODsip:proxy1
Route:,,,
IfthefirstURIoftheroutesetdoesnotcontainthelr
parameter,theproxyindicateddoesnotunderstandtherouting
mechanismsdescribedinthisdocumentandwillactasspecifiedin
RFC2543,replacingtheRequest-URIwiththefirstRouteheader
fieldvalueitreceiveswhileforwardingthemessage.Placingthe
Request-URIattheendoftheRouteheaderfieldpreservesthe
Rosenberg,et.al.StandardsTrack[Page74]
RFC3261SIP:SessionInitiationProtocolJune2002
informationinthatRequest-URIacrossthestrictrouter(itwill
bereturnedtotheRequest-URIwhentherequestreachesaloose-
router).
AUACSHOULDincludeaContactheaderfieldinanytargetrefresh
requestswithinadialog,andunlessthereisaneedtochangeit,
theURISHOULDbethesameasusedinpreviousrequestswithinthe
dialog.Ifthe"secure"flagistrue,thatURIMUSTbeaSIPSURI.
AsdiscussedinSection12.2.2,aContactheaderfieldinatarget
refreshrequestupdatestheremotetargetURI.ThisallowsaUAto
provideanewcontactaddress,shoulditsaddresschangeduringthe
durationofthedialog.
However,requeststhatarenottargetrefreshrequestsdonotaffect
theremotetargetURIforthedialog.
TherestoftherequestisformedasdescribedinSection8.1.1.
Oncetherequesthasbeenconstructed,theaddressoftheserveris
computedandtherequestissent,usingthesameproceduresfor
requestsoutsideofadialog(Section8.1.2).
TheproceduresinSection8.1.2willnormallyresultinthe
requestbeingsenttotheaddressindicatedbythetopmostRoute
headerfieldvalueortheRequest-URIifnoRouteheaderfieldis
present.Subjecttocertainrestrictions,theyallowtherequest
tobesenttoanalternateaddress(suchasadefaultoutbound
proxynotrepresentedintherouteset).
12.2.1.2ProcessingtheResponses
TheUACwillreceiveresponsestotherequestfromthetransaction
layer.Iftheclienttransactionreturnsatimeout,thisistreated
asa408(RequestTimeout)response.
ThebehaviorofaUACthatreceivesa3xxresponseforarequestsent
withinadialogisthesameasiftherequesthadbeensentoutsidea
dialog.ThisbehaviorisdescribedinSection8.1.3.4.
Note,however,thatwhentheUACtriesalternativelocations,it
stillusestheroutesetforthedialogtobuildtheRouteheader
oftherequest.
WhenaUACreceivesa2xxresponsetoatargetrefreshrequest,it
MUSTreplacethedialog'sremotetargetURIwiththeURIfromthe
Contactheaderfieldinthatresponse,ifpresent.
Rosenberg,et.al.StandardsTrack[Page75]
RFC3261SIP:SessionInitiationProtocolJune2002
Iftheresponseforarequestwithinadialogisa481
(Call/TransactionDoesNotExist)ora408(RequestTimeout),theUAC
SHOULDterminatethedialog.AUACSHOULDalsoterminateadialogif
noresponseatallisreceivedfortherequest(theclient
transactionwouldinformtheTUaboutthetimeout.)
ForINVITEinitiateddialogs,terminatingthedialogconsistsof
sendingaBYE.
12.2.2UASBehavior
Requestssentwithinadialog,asanyotherrequests,areatomic.If
aparticularrequestisacceptedbytheUAS,allthestatechanges
associatedwithitareperformed.Iftherequestisrejected,none
ofthestatechangesareperformed.
Notethatsomerequests,suchasINVITEs,affectseveralpiecesof
state.
TheUASwillreceivetherequestfromthetransactionlayer.Ifthe
requesthasatagintheToheaderfield,theUAScorecomputesthe
dialogidentifiercorrespondingtotherequestandcomparesitwith
existingdialogs.Ifthereisamatch,thisisamid-dialogrequest.
Inthatcase,theUASfirstappliesthesameprocessingrulesfor
requestsoutsideofadialog,discussedinSection8.2.
IftherequesthasatagintheToheaderfield,butthedialog
identifierdoesnotmatchanyexistingdialogs,theUASmayhave
crashedandrestarted,oritmayhavereceivedarequestfora
different(possiblyfailed)UAS(theUASscanconstructtheTotags
sothataUAScanidentifythatthetagwasforaUASforwhichitis
providingrecovery).Anotherpossibilityisthattheincoming
requesthasbeensimplymisrouted.BasedontheTotag,theUASMAY
eitheracceptorrejecttherequest.Acceptingtherequestfor
acceptableTotagsprovidesrobustness,sothatdialogscanpersist
eventhroughcrashes.UAswishingtosupportthiscapabilitymust
takeintoconsiderationsomeissuessuchaschoosingmonotonically
increasingCSeqsequencenumbersevenacrossreboots,reconstructing
therouteset,andacceptingout-of-rangeRTPtimestampsandsequence
numbers.
IftheUASwishestorejecttherequestbecauseitdoesnotwishto
recreatethedialog,itMUSTrespondtotherequestwitha481
(Call/TransactionDoesNotExist)statuscodeandpassthattothe
servertransaction.
Rosenberg,et.al.StandardsTrack[Page76]
RFC3261SIP:SessionInitiationProtocolJune2002
Requeststhatdonotchangeinanywaythestateofadialogmaybe
receivedwithinadialog(forexample,anOPTIONSrequest).Theyare
processedasiftheyhadbeenreceivedoutsidethedialog.
Iftheremotesequencenumberisempty,itMUSTbesettothevalue
ofthesequencenumberintheCSeqheaderfieldvalueintherequest.
Iftheremotesequencenumberwasnotempty,butthesequencenumber
oftherequestislowerthantheremotesequencenumber,therequest
isoutoforderandMUSTberejectedwitha500(ServerInternal
Error)response.Iftheremotesequencenumberwasnotempty,and
thesequencenumberoftherequestisgreaterthantheremote
sequencenumber,therequestisinorder.Itispossibleforthe
CSeqsequencenumbertobehigherthantheremotesequencenumberby
morethanone.Thisisnotanerrorcondition,andaUASSHOULDbe
preparedtoreceiveandprocessrequestswithCSeqvaluesmorethan
onehigherthanthepreviousreceivedrequest.TheUASMUSTthenset
theremotesequencenumbertothevalueofthesequencenumberinthe
CSeqheaderfieldvalueintherequest.
IfaproxychallengesarequestgeneratedbytheUAC,theUAChas
toresubmittherequestwithcredentials.Theresubmittedrequest
willhaveanewCSeqnumber.TheUASwillneverseethefirst
request,andthus,itwillnoticeagapintheCSeqnumberspace.
Suchagapdoesnotrepresentanyerrorcondition.
WhenaUASreceivesatargetrefreshrequest,itMUSTreplacethe
dialog'sremotetargetURIwiththeURIfromtheContactheaderfield
inthatrequest,ifpresent.
12.3TerminationofaDialog
Independentofthemethod,ifarequestoutsideofadialoggenerates
anon-2xxfinalresponse,anyearlydialogscreatedthrough
provisionalresponsestothatrequestareterminated.Themechanism
forterminatingconfirmeddialogsismethodspecific.Inthis
specification,theBYEmethodterminatesasessionandthedialog
associatedwithit.SeeSection15fordetails.
13InitiatingaSession
13.1Overview
Whenauseragentclientdesirestoinitiateasession(forexample,
audio,video,oragame),itformulatesanINVITErequest.The
INVITErequestasksaservertoestablishasession.Thisrequest
maybeforwardedbyproxies,eventuallyarrivingatoneormoreUAS
thatcanpotentiallyaccepttheinvitation.TheseUASswill
frequentlyneedtoquerytheuseraboutwhethertoacceptthe
Rosenberg,et.al.StandardsTrack[Page77]
RFC3261SIP:SessionInitiationProtocolJune2002
invitation.Aftersometime,thoseUASscanaccepttheinvitation
(meaningthesessionistobeestablished)bysendinga2xxresponse.
Iftheinvitationisnotaccepted,a3xx,4xx,5xxor6xxresponseis
sent,dependingonthereasonfortherejection.Beforesendinga
finalresponse,theUAScanalsosendprovisionalresponses(1xx)to
advisetheUACofprogressincontactingthecalleduser.
Afterpossiblyreceivingoneormoreprovisionalresponses,theUAC
willgetoneormore2xxresponsesoronenon-2xxfinalresponse.
Becauseoftheprotractedamountoftimeitcantaketoreceivefinal
responsestoINVITE,thereliabilitymechanismsforINVITE
transactionsdifferfromthoseofotherrequests(likeOPTIONS).
Onceitreceivesafinalresponse,theUACneedstosendanACKfor
everyfinalresponseitreceives.TheprocedureforsendingthisACK
dependsonthetypeofresponse.Forfinalresponsesbetween300and
699,theACKprocessingisdoneinthetransactionlayerandfollows
onesetofrules(SeeSection17).For2xxresponses,theACKis
generatedbytheUACcore.
A2xxresponsetoanINVITEestablishesasession,anditalso
createsadialogbetweentheUAthatissuedtheINVITEandtheUA
thatgeneratedthe2xxresponse.Therefore,whenmultiple2xx
responsesarereceivedfromdifferentremoteUAs(becausetheINVITE
forked),each2xxestablishesadifferentdialog.Allthesedialogs
arepartofthesamecall.
Thissectionprovidesdetailsontheestablishmentofasessionusing
INVITE.AUAthatsupportsINVITEMUSTalsosupportACK,CANCELand
BYE.
13.2UACProcessing
13.2.1CreatingtheInitialINVITE
SincetheinitialINVITErepresentsarequestoutsideofadialog,
itsconstructionfollowstheproceduresofSection8.1.1.Additional
processingisrequiredforthespecificcaseofINVITE.
AnAllowheaderfield(Section20.5)SHOULDbepresentintheINVITE.
Itindicateswhatmethodscanbeinvokedwithinadialog,ontheUA
sendingtheINVITE,forthedurationofthedialog.Forexample,a
UAcapableofreceivingINFOrequestswithinadialog[34]SHOULD
includeanAllowheaderfieldlistingtheINFOmethod.
ASupportedheaderfield(Section20.37)SHOULDbepresentinthe
INVITE.ItenumeratesalltheextensionsunderstoodbytheUAC.
Rosenberg,et.al.StandardsTrack[Page78]
RFC3261SIP:SessionInitiationProtocolJune2002
AnAccept(Section20.1)headerfieldMAYbepresentintheINVITE.
ItindicateswhichContent-TypesareacceptabletotheUA,inboth
theresponsereceivedbyit,andinanysubsequentrequestssentto
itwithindialogsestablishedbytheINVITE.TheAcceptheaderfield
isespeciallyusefulforindicatingsupportofvarioussession
descriptionformats.
TheUACMAYaddanExpiresheaderfield(Section20.19)tolimitthe
validityoftheinvitation.IfthetimeindicatedintheExpires
headerfieldisreachedandnofinalanswerfortheINVITEhasbeen
received,theUACcoreSHOULDgenerateaCANCELrequestforthe
INVITE,asperSection9.
AUACMAYalsofinditusefultoadd,amongothers,Subject(Section
20.36),Organization(Section20.25)andUser-Agent(Section20.41)
headerfields.TheyallcontaininformationrelatedtotheINVITE.
TheUACMAYchoosetoaddamessagebodytotheINVITE.Section
8.1.1.10dealswithhowtoconstructtheheaderfields--Content-
Typeamongothers--neededtodescribethemessagebody.
Therearespecialrulesformessagebodiesthatcontainasession
description-theircorrespondingContent-Dispositionis"session".
SIPusesanoffer/answermodelwhereoneUAsendsasession
description,calledtheoffer,whichcontainsaproposeddescription
ofthesession.Theofferindicatesthedesiredcommunicationsmeans
(audio,video,games),parametersofthosemeans(suchascodec
types)andaddressesforreceivingmediafromtheanswerer.The
otherUArespondswithanothersessiondescription,calledthe
answer,whichindicateswhichcommunicationsmeansareaccepted,the
parametersthatapplytothosemeans,andaddressesforreceiving
mediafromtheofferer.Anoffer/answerexchangeiswithinthe
contextofadialog,sothatifaSIPINVITEresultsinmultiple
dialogs,eachisaseparateoffer/answerexchange.Theoffer/answer
modeldefinesrestrictionsonwhenoffersandanswerscanbemade
(forexample,youcannotmakeanewofferwhileoneisinprogress).
Thisresultsinrestrictionsonwheretheoffersandanswerscan
appearinSIPmessages.Inthisspecification,offersandanswers
canonlyappearinINVITErequestsandresponses,andACK.Theusage
ofoffersandanswersisfurtherrestricted.FortheinitialINVITE
transaction,therulesare:
oTheinitialofferMUSTbeineitheranINVITEor,ifnotthere,
inthefirstreliablenon-failuremessagefromtheUASbackto
theUAC.Inthisspecification,thatisthefinal2xx
response.
Rosenberg,et.al.StandardsTrack[Page79]
RFC3261SIP:SessionInitiationProtocolJune2002
oIftheinitialofferisinanINVITE,theanswerMUSTbeina
reliablenon-failuremessagefromUASbacktoUACwhichis
correlatedtothatINVITE.Forthisspecification,thatis
onlythefinal2xxresponsetothatINVITE.Thatsameexact
answerMAYalsobeplacedinanyprovisionalresponsessent
priortotheanswer.TheUACMUSTtreatthefirstsession
descriptionitreceivesastheanswer,andMUSTignoreany
sessiondescriptionsinsubsequentresponsestotheinitial
INVITE.
oIftheinitialofferisinthefirstreliablenon-failure
messagefromtheUASbacktoUAC,theanswerMUSTbeinthe
acknowledgementforthatmessage(inthisspecification,ACK
fora2xxresponse).
oAfterhavingsentorreceivedananswertothefirstoffer,the
UACMAYgeneratesubsequentoffersinrequestsbasedonrules
specifiedforthatmethod,butonlyifithasreceivedanswers
toanypreviousoffers,andhasnotsentanyofferstowhichit
hasn'tgottenananswer.
oOncetheUAShassentorreceivedananswertotheinitial
offer,itMUSTNOTgeneratesubsequentoffersinanyresponses
totheinitialINVITE.ThismeansthataUASbasedonthis
specificationalonecannevergeneratesubsequentoffersuntil
completionoftheinitialtransaction.
Concretely,theaboverulesspecifytwoexchangesforUAscompliant
tothisspecificationalone-theofferisintheINVITE,andthe
answerinthe2xx(andpossiblyina1xxaswell,withthesame
value),ortheofferisinthe2xx,andtheanswerisintheACK.
AlluseragentsthatsupportINVITEMUSTsupportthesetwoexchanges.
TheSessionDescriptionProtocol(SDP)(RFC2327[1])MUSTbe
supportedbyalluseragentsasameanstodescribesessions,andits
usageforconstructingoffersandanswersMUSTfollowtheprocedures
definedin[13].
Therestrictionsoftheoffer-answermodeljustdescribedonlyapply
tobodieswhoseContent-Dispositionheaderfieldvalueis"session".
Therefore,itispossiblethatboththeINVITEandtheACKcontaina
bodymessage(forexample,theINVITEcarriesaphoto(Content-
Disposition:render)andtheACKasessiondescription(Content-
Disposition:session)).
IftheContent-Dispositionheaderfieldismissing,bodiesof
Content-Typeapplication/sdpimplythedisposition"session",while
othercontenttypesimply"render".
Rosenberg,et.al.StandardsTrack[Page80]
RFC3261SIP:SessionInitiationProtocolJune2002
OncetheINVITEhasbeencreated,theUACfollowstheprocedures
definedforsendingrequestsoutsideofadialog(Section8).This
resultsintheconstructionofaclienttransactionthatwill
ultimatelysendtherequestanddeliverresponsestotheUAC.
13.2.2ProcessingINVITEResponses
OncetheINVITEhasbeenpassedtotheINVITEclienttransaction,the
UACwaitsforresponsesfortheINVITE.IftheINVITEclient
transactionreturnsatimeoutratherthanaresponsetheTUactsas
ifa408(RequestTimeout)responsehadbeenreceived,asdescribed
inSection8.1.3.
13.2.2.11xxResponses
Zero,oneormultipleprovisionalresponsesmayarrivebeforeoneor
morefinalresponsesarereceived.Provisionalresponsesforan
INVITErequestcancreate"earlydialogs".Ifaprovisionalresponse
hasatagintheTofield,andifthedialogIDoftheresponsedoes
notmatchanexistingdialog,oneisconstructedusingtheprocedures
definedinSection12.1.2.
TheearlydialogwillonlybeneedediftheUACneedstosenda
requesttoitspeerwithinthedialogbeforetheinitialINVITE
transactioncompletes.Headerfieldspresentinaprovisional
responseareapplicableaslongasthedialogisintheearlystate
(forexample,anAllowheaderfieldinaprovisionalresponse
containsthemethodsthatcanbeusedinthedialogwhilethisisin
theearlystate).
13.2.2.23xxResponses
A3xxresponsemaycontainoneormoreContactheaderfieldvalues
providingnewaddresseswherethecalleemightbereachable.
Dependingonthestatuscodeofthe3xxresponse(seeSection21.3),
theUACMAYchoosetotrythosenewaddresses.
13.2.2.34xx,5xxand6xxResponses
Asinglenon-2xxfinalresponsemaybereceivedfortheINVITE.4xx,
5xxand6xxresponsesmaycontainaContactheaderfieldvalue
indicatingthelocationwhereadditionalinformationabouttheerror
canbefound.Subsequentfinalresponses(whichwouldonlyarrive
undererrorconditions)MUSTbeignored.
Allearlydialogsareconsideredterminateduponreceptionofthe
non-2xxfinalresponse.
Rosenberg,et.al.StandardsTrack[Page81]
RFC3261SIP:SessionInitiationProtocolJune2002
Afterhavingreceivedthenon-2xxfinalresponsetheUACcore
considerstheINVITEtransactioncompleted.TheINVITEclient
transactionhandlesthegenerationofACKsfortheresponse(see
Section17).
13.2.2.42xxResponses
Multiple2xxresponsesmayarriveattheUACforasingleINVITE
requestduetoaforkingproxy.Eachresponseisdistinguishedby
thetagparameterintheToheaderfield,andeachrepresentsa
distinctdialog,withadistinctdialogidentifier.
Ifthedialogidentifierinthe2xxresponsematchesthedialog
identifierofanexistingdialog,thedialogMUSTbetransitionedto
the"confirmed"state,andtheroutesetforthedialogMUSTbe
recomputedbasedonthe2xxresponseusingtheproceduresofSection
12.2.1.2.Otherwise,anewdialoginthe"confirmed"stateMUSTbe
constructedusingtheproceduresofSection12.1.2.
Notethattheonlypieceofstatethatisrecomputedistheroute
set.Otherpiecesofstatesuchasthehighestsequencenumbers
(remoteandlocal)sentwithinthedialogarenotrecomputed.The
routesetonlyisrecomputedforbackwardscompatibility.RFC
2543didnotmandatemirroringoftheRecord-Routeheaderfieldin
a1xx,only2xx.However,wecannotupdatetheentirestateof
thedialog,sincemid-dialogrequestsmayhavebeensentwithin
theearlydialog,modifyingthesequencenumbers,forexample.
TheUACcoreMUSTgenerateanACKrequestforeach2xxreceivedfrom
thetransactionlayer.TheheaderfieldsoftheACKareconstructed
inthesamewayasforanyrequestsentwithinadialog(seeSection
12)withtheexceptionoftheCSeqandtheheaderfieldsrelatedto
authentication.ThesequencenumberoftheCSeqheaderfieldMUSTbe
thesameastheINVITEbeingacknowledged,buttheCSeqmethodMUST
beACK.TheACKMUSTcontainthesamecredentialsastheINVITE.If
the2xxcontainsanoffer(basedontherulesabove),theACKMUST
carryananswerinitsbody.Iftheofferinthe2xxresponseisnot
acceptable,theUACcoreMUSTgenerateavalidanswerintheACKand
thensendaBYEimmediately.
OncetheACKhasbeenconstructed,theproceduresof[4]areusedto
determinethedestinationaddress,portandtransport.However,the
requestispassedtothetransportlayerdirectlyfortransmission,
ratherthanaclienttransaction.ThisisbecausetheUACcore
handlesretransmissionsoftheACK,notthetransactionlayer.The
ACKMUSTbepassedtotheclienttransporteverytimea
retransmissionofthe2xxfinalresponsethattriggeredtheACK
arrives.
Rosenberg,et.al.StandardsTrack[Page82]
RFC3261SIP:SessionInitiationProtocolJune2002
TheUACcoreconsiderstheINVITEtransactioncompleted64*T1seconds
afterthereceptionofthefirst2xxresponse.Atthispointallthe
earlydialogsthathavenottransitionedtoestablisheddialogsare
terminated.OncetheINVITEtransactionisconsideredcompletedby
theUACcore,nomorenew2xxresponsesareexpectedtoarrive.
If,afteracknowledgingany2xxresponsetoanINVITE,theUACdoes
notwanttocontinuewiththatdialog,thentheUACMUSTterminate
thedialogbysendingaBYErequestasdescribedinSection15.
13.3UASProcessing
13.3.1ProcessingoftheINVITE
TheUAScorewillreceiveINVITErequestsfromthetransactionlayer.
ItfirstperformstherequestprocessingproceduresofSection8.2,
whichareappliedforbothrequestsinsideandoutsideofadialog.
Assumingtheseprocessingstatesarecompletedwithoutgeneratinga
response,theUAScoreperformstheadditionalprocessingsteps:
1.IftherequestisanINVITEthatcontainsanExpiresheader
field,theUAScoresetsatimerforthenumberofseconds
indicatedintheheaderfieldvalue.Whenthetimerfires,the
invitationisconsideredtobeexpired.Iftheinvitation
expiresbeforetheUAShasgeneratedafinalresponse,a487
(RequestTerminated)responseSHOULDbegenerated.
2.Iftherequestisamid-dialogrequest,themethod-independent
processingdescribedinSection12.2.2isfirstapplied.It
mightalsomodifythesession;Section14providesdetails.
3.IftherequesthasatagintheToheaderfieldbutthedialog
identifierdoesnotmatchanyoftheexistingdialogs,theUAS
mayhavecrashedandrestarted,ormayhavereceivedarequest
foradifferent(possiblyfailed)UAS.Section12.2.2provides
guidelinestoachievearobustbehaviorundersuchasituation.
ProcessingfromhereforwardassumesthattheINVITEisoutsideofa
dialog,andisthusforthepurposesofestablishinganewsession.
TheINVITEmaycontainasessiondescription,inwhichcasetheUAS
isbeingpresentedwithanofferforthatsession.Itispossible
thattheuserisalreadyaparticipantinthatsession,eventhough
theINVITEisoutsideofadialog.Thiscanhappenwhenauseris
invitedtothesamemulticastconferencebymultipleother
participants.Ifdesired,theUASMAYuseidentifierswithinthe
sessiondescriptiontodetectthisduplication.Forexample,SDP
Rosenberg,et.al.StandardsTrack[Page83]
RFC3261SIP:SessionInitiationProtocolJune2002
containsasessionidandversionnumberintheorigin(o)field.If
theuserisalreadyamemberofthesession,andthesession
parameterscontainedinthesessiondescriptionhavenotchanged,the
UASMAYsilentlyaccepttheINVITE(thatis,senda2xxresponse
withoutpromptingtheuser).
IftheINVITEdoesnotcontainasessiondescription,theUASis
beingaskedtoparticipateinasession,andtheUAChasaskedthat
theUASprovidetheofferofthesession.ItMUSTprovidetheoffer
initsfirstnon-failurereliablemessagebacktotheUAC.Inthis
specification,thatisa2xxresponsetotheINVITE.
TheUAScanindicateprogress,accept,redirect,orrejectthe
invitation.Inallofthesecases,itformulatesaresponseusing
theproceduresdescribedinSection8.2.6.
13.3.1.1Progress
IftheUASisnotabletoanswertheinvitationimmediately,itcan
choosetoindicatesomekindofprogresstotheUAC(forexample,an
indicationthataphoneisringing).Thisisaccomplishedwitha
provisionalresponsebetween101and199.Theseprovisional
responsesestablishearlydialogsandthereforefollowtheprocedures
ofSection12.1.1inadditiontothoseofSection8.2.6.AUASMAY
sendasmanyprovisionalresponsesasitlikes.EachoftheseMUST
indicatethesamedialogID.However,thesewillnotbedelivered
reliably.
IftheUASdesiresanextendedperiodoftimetoanswertheINVITE,
itwillneedtoaskforan"extension"inordertopreventproxies
fromcancelingthetransaction.Aproxyhastheoptionofcanceling
atransactionwhenthereisagapof3minutesbetweenresponsesina
transaction.Topreventcancellation,theUASMUSTsendanon-100
provisionalresponseateveryminute,tohandlethepossibilityof
lostprovisionalresponses.
AnINVITEtransactioncangoonforextendeddurationswhenthe
userisplacedonhold,orwheninterworkingwithPSTNsystems
whichallowcommunicationstotakeplacewithoutansweringthe
call.ThelatteriscommoninInteractiveVoiceResponse(IVR)
systems.
13.3.1.2TheINVITEisRedirected
IftheUASdecidestoredirectthecall,a3xxresponseissent.A
300(MultipleChoices),301(MovedPermanently)or302(Moved
Temporarily)responseSHOULDcontainaContactheaderfield
Rosenberg,et.al.StandardsTrack[Page84]
RFC3261SIP:SessionInitiationProtocolJune2002
containingoneormoreURIsofnewaddressestobetried.The
responseispassedtotheINVITEservertransaction,whichwilldeal
withitsretransmissions.
13.3.1.3TheINVITEisRejected
Acommonscenariooccurswhenthecalleeiscurrentlynotwillingor
abletotakeadditionalcallsatthisendsystem.A486(BusyHere)
SHOULDbereturnedinsuchascenario.IftheUASknowsthatno
otherendsystemwillbeabletoacceptthiscall,a600(Busy
Everywhere)responseSHOULDbesentinstead.However,itisunlikely
thataUASwillbeabletoknowthisingeneral,andthusthis
responsewillnotusuallybeused.Theresponseispassedtothe
INVITEservertransaction,whichwilldealwithitsretransmissions.
AUASrejectinganoffercontainedinanINVITESHOULDreturna488
(NotAcceptableHere)response.SucharesponseSHOULDincludea
Warningheaderfieldvalueexplainingwhytheofferwasrejected.
13.3.1.4TheINVITEisAccepted
TheUAScoregeneratesa2xxresponse.Thisresponseestablishesa
dialog,andthereforefollowstheproceduresofSection12.1.1in
additiontothoseofSection8.2.6.
A2xxresponsetoanINVITESHOULDcontaintheAllowheaderfieldand
theSupportedheaderfield,andMAYcontaintheAcceptheaderfield.
IncludingtheseheaderfieldsallowstheUACtodeterminethe
featuresandextensionssupportedbytheUASforthedurationofthe
call,withoutprobing.
IftheINVITErequestcontainedanoffer,andtheUAShadnotyet
sentananswer,the2xxMUSTcontainananswer.IftheINVITEdid
notcontainanoffer,the2xxMUSTcontainanofferiftheUAShad
notyetsentanoffer.
Oncetheresponsehasbeenconstructed,itispassedtotheINVITE
servertransaction.Note,however,thattheINVITEserver
transactionwillbedestroyedassoonasitreceivesthisfinal
responseandpassesittothetransport.Therefore,itisnecessary
toperiodicallypasstheresponsedirectlytothetransportuntilthe
ACKarrives.The2xxresponseispassedtothetransportwithan
intervalthatstartsatT1secondsanddoublesforeach
retransmissionuntilitreachesT2seconds(T1andT2aredefinedin
Section17).ResponseretransmissionsceasewhenanACKrequestfor
theresponseisreceived.Thisisindependentofwhatevertransport
protocolsareusedtosendtheresponse.
Rosenberg,et.al.StandardsTrack[Page85]
RFC3261SIP:SessionInitiationProtocolJune2002
Since2xxisretransmittedend-to-end,theremaybehopsbetween
UASandUACthatareUDP.Toensurereliabledeliveryacross
thesehops,theresponseisretransmittedperiodicallyevenifthe
transportattheUASisreliable.
Iftheserverretransmitsthe2xxresponsefor64*T1secondswithout
receivinganACK,thedialogisconfirmed,butthesessionSHOULDbe
terminated.ThisisaccomplishedwithaBYE,asdescribedinSection
15.
14ModifyinganExistingSession
AsuccessfulINVITErequest(seeSection13)establishesbotha
dialogbetweentwouseragentsandasessionusingtheoffer-answer
model.Section12explainshowtomodifyanexistingdialogusinga
targetrefreshrequest(forexample,changingtheremotetargetURI
ofthedialog).Thissectiondescribeshowtomodifytheactual
session.Thismodificationcaninvolvechangingaddressesorports,
addingamediastream,deletingamediastream,andsoon.Thisis
accomplishedbysendinganewINVITErequestwithinthesamedialog
thatestablishedthesession.AnINVITErequestsentwithinan
existingdialogisknownasare-INVITE.
Notethatasinglere-INVITEcanmodifythedialogandthe
parametersofthesessionatthesametime.
Eitherthecallerorcalleecanmodifyanexistingsession.
ThebehaviorofaUAondetectionofmediafailureisamatterof
localpolicy.However,automatedgenerationofre-INVITEorBYEis
NOTRECOMMENDEDtoavoidfloodingthenetworkwithtrafficwhenthere
iscongestion.Inanycase,ifthesemessagesaresent
automatically,theySHOULDbesentaftersomerandomizedinterval.
Notethattheparagraphabovereferstoautomaticallygenerated
BYEsandre-INVITEs.Iftheuserhangsupuponmediafailure,the
UAwouldsendaBYErequestasusual.
14.1UACBehavior
Thesameoffer-answermodelthatappliestosessiondescriptionsin
INVITEs(Section13.2.1)appliestore-INVITEs.Asaresult,aUAC
thatwantstoaddamediastream,forexample,willcreateanew
offerthatcontainsthismediastream,andsendthatinanINVITE
requesttoitspeer.Itisimportanttonotethatthefull
descriptionofthesession,notjustthechange,issent.This
supportsstatelesssessionprocessinginvariouselements,and
supportsfailoverandrecoverycapabilities.Ofcourse,aUACMAY
Rosenberg,et.al.StandardsTrack[Page86]
RFC3261SIP:SessionInitiationProtocolJune2002
sendare-INVITEwithnosessiondescription,inwhichcasethefirst
reliablenon-failureresponsetothere-INVITEwillcontaintheoffer
(inthisspecification,thatisa2xxresponse).
Ifthesessiondescriptionformathasthecapabilityforversion
numbers,theoffererSHOULDindicatethattheversionofthesession
descriptionhaschanged.
TheTo,From,Call-ID,CSeq,andRequest-URIofare-INVITEareset
followingthesamerulesasforregularrequestswithinanexisting
dialog,describedinSection12.
AUACMAYchoosenottoaddanAlert-Infoheaderfieldorabodywith
Content-Disposition"alert"tore-INVITEsbecauseUASsdonot
typicallyalerttheuseruponreceptionofare-INVITE.
UnlikeanINVITE,whichcanfork,are-INVITEwillneverfork,and
therefore,onlyevergenerateasinglefinalresponse.Thereasona
re-INVITEwillneverforkisthattheRequest-URIidentifiesthe
targetastheUAinstanceitestablishedthedialogwith,ratherthan
identifyinganaddress-of-recordfortheuser.
NotethataUACMUSTNOTinitiateanewINVITEtransactionwithina
dialogwhileanotherINVITEtransactionisinprogressineither
direction.
1.IfthereisanongoingINVITEclienttransaction,theTUMUST
waituntilthetransactionreachesthecompletedorterminated
statebeforeinitiatingthenewINVITE.
2.IfthereisanongoingINVITEservertransaction,theTUMUST
waituntilthetransactionreachestheconfirmedorterminated
statebeforeinitiatingthenewINVITE.
However,aUAMAYinitiatearegulartransactionwhileanINVITE
transactionisinprogress.AUAMAYalsoinitiateanINVITE
transactionwhilearegulartransactionisinprogress.
IfaUAreceivesanon-2xxfinalresponsetoare-INVITE,thesession
parametersMUSTremainunchanged,asifnore-INVITEhadbeenissued.
Notethat,asstatedinSection12.2.1.2,ifthenon-2xxfinal
responseisa481(Call/TransactionDoesNotExist),ora408
(RequestTimeout),ornoresponseatallisreceivedforthere-
INVITE(thatis,atimeoutisreturnedbytheINVITEclient
transaction),theUACwillterminatethedialog.
Rosenberg,et.al.StandardsTrack[Page87]
RFC3261SIP:SessionInitiationProtocolJune2002
IfaUACreceivesa491responsetoare-INVITE,itSHOULDstarta
timerwithavalueTchosenasfollows:
1.IftheUACistheowneroftheCall-IDofthedialogID
(meaningitgeneratedthevalue),Thasarandomlychosenvalue
between2.1and4secondsinunitsof10ms.
2.IftheUACisnottheowneroftheCall-IDofthedialogID,T
hasarandomlychosenvalueofbetween0and2secondsinunits
of10ms.
Whenthetimerfires,theUACSHOULDattemptthere-INVITEoncemore,
ifitstilldesiresforthatsessionmodificationtotakeplace.For
example,ifthecallwasalreadyhungupwithaBYE,there-INVITE
wouldnottakeplace.
Therulesfortransmittingare-INVITEandforgeneratinganACKfor
a2xxresponsetore-INVITEarethesameasfortheinitialINVITE
(Section13.2.1).
14.2UASBehavior
Section13.3.1describestheprocedurefordistinguishingincoming
re-INVITEsfromincominginitialINVITEsandhandlingare-INVITEfor
anexistingdialog.
AUASthatreceivesasecondINVITEbeforeitsendsthefinal
responsetoafirstINVITEwithalowerCSeqsequencenumberonthe
samedialogMUSTreturna500(ServerInternalError)responsetothe
secondINVITEandMUSTincludeaRetry-Afterheaderfieldwitha
randomlychosenvalueofbetween0and10seconds.
AUASthatreceivesanINVITEonadialogwhileanINVITEithadsent
onthatdialogisinprogressMUSTreturna491(RequestPending)
responsetothereceivedINVITE.
IfaUAreceivesare-INVITEforanexistingdialog,itMUSTcheck
anyversionidentifiersinthesessiondescriptionor,ifthereare
noversionidentifiers,thecontentofthesessiondescriptiontosee
ifithaschanged.Ifthesessiondescriptionhaschanged,theUAS
MUSTadjustthesessionparametersaccordingly,possiblyafterasking
theuserforconfirmation.
Versioningofthesessiondescriptioncanbeusedtoaccommodate
thecapabilitiesofnewarrivalstoaconference,addordelete
media,orchangefromaunicasttoamulticastconference.
Rosenberg,et.al.StandardsTrack[Page88]
RFC3261SIP:SessionInitiationProtocolJune2002
Ifthenewsessiondescriptionisnotacceptable,theUAScanreject
itbyreturninga488(NotAcceptableHere)responseforthere-
INVITE.ThisresponseSHOULDincludeaWarningheaderfield.
IfaUASgeneratesa2xxresponseandneverreceivesanACK,it
SHOULDgenerateaBYEtoterminatethedialog.
AUASMAYchoosenottogenerate180(Ringing)responsesforare-
INVITEbecauseUACsdonottypicallyrenderthisinformationtothe
user.Forthesamereason,UASsMAYchoosenottouseanAlert-Info
headerfieldorabodywithContent-Disposition"alert"inresponses
toare-INVITE.
AUASprovidinganofferina2xx(becausetheINVITEdidnotcontain
anoffer)SHOULDconstructtheofferasiftheUASweremakinga
brandnewcall,subjecttotheconstraintsofsendinganofferthat
updatesanexistingsession,asdescribedin[13]inthecaseofSDP.
Specifically,thismeansthatitSHOULDincludeasmanymediaformats
andmediatypesthattheUAiswillingtosupport.TheUASMUST
ensurethatthesessiondescriptionoverlapswithitsprevious
sessiondescriptioninmediaformats,transports,orotherparameters
thatrequiresupportfromthepeer.Thisistoavoidtheneedfor
thepeertorejectthesessiondescription.If,however,itis
unacceptabletotheUAC,theUACSHOULDgenerateananswerwitha
validsessiondescription,andthensendaBYEtoterminatethe
session.
15TerminatingaSession
Thissectiondescribestheproceduresforterminatingasession
establishedbySIP.Thestateofthesessionandthestateofthe
dialogareverycloselyrelated.Whenasessionisinitiatedwithan
INVITE,each1xxor2xxresponsefromadistinctUAScreatesa
dialog,andifthatresponsecompletestheoffer/answerexchange,it
alsocreatesasession.Asaresult,eachsessionis"associated"
withasingledialog-theonewhichresultedinitscreation.Ifan
initialINVITEgeneratesanon-2xxfinalresponse,thatterminates
allsessions(ifany)andalldialogs(ifany)thatwerecreated
throughresponsestotherequest.Byvirtueofcompletingthe
transaction,anon-2xxfinalresponsealsopreventsfurthersessions
frombeingcreatedasaresultoftheINVITE.TheBYErequestis
usedtoterminateaspecificsessionorattemptedsession.Inthis
case,thespecificsessionistheonewiththepeerUAontheother
sideofthedialog.WhenaBYEisreceivedonadialog,anysession
associatedwiththatdialogSHOULDterminate.AUAMUSTNOTsenda
BYEoutsideofadialog.Thecaller'sUAMAYsendaBYEforeither
confirmedorearlydialogs,andthecallee'sUAMAYsendaBYEon
confirmeddialogs,butMUSTNOTsendaBYEonearlydialogs.
Rosenberg,et.al.StandardsTrack[Page89]
RFC3261SIP:SessionInitiationProtocolJune2002
However,thecallee'sUAMUSTNOTsendaBYEonaconfirmeddialog
untilithasreceivedanACKforits2xxresponseoruntiltheserver
transactiontimesout.IfnoSIPextensionshavedefinedother
applicationlayerstatesassociatedwiththedialog,theBYEalso
terminatesthedialog.
Theimpactofanon-2xxfinalresponsetoINVITEondialogsand
sessionsmakestheuseofCANCELattractive.TheCANCELattemptsto
forceanon-2xxresponsetotheINVITE(inparticular,a487).
Therefore,ifaUACwishestogiveuponitscallattemptentirely,
itcansendaCANCEL.IftheINVITEresultsin2xxfinalresponse(s)
totheINVITE,thismeansthataUASacceptedtheinvitationwhile
theCANCELwasinprogress.TheUACMAYcontinuewiththesessions
establishedbyany2xxresponses,orMAYterminatethemwithBYE.
Thenotionof"hangingup"isnotwelldefinedwithinSIP.Itis
specifictoaparticular,albeitcommon,userinterface.
Typically,whentheuserhangsup,itindicatesadesireto
terminatetheattempttoestablishasession,andtoterminateany
sessionsalreadycreated.Forthecaller'sUA,thiswouldimplya
CANCELrequestiftheinitialINVITEhasnotgeneratedafinal
response,andaBYEtoallconfirmeddialogsafterafinal
response.Forthecallee'sUA,itwouldtypicallyimplyaBYE;
presumably,whentheuserpickedupthephone,a2xxwas
generated,andsohangingupwouldresultinaBYEaftertheACK
isreceived.Thisdoesnotmeanausercannothangupbefore
receiptoftheACK,itjustmeansthatthesoftwareinhisphone
needstomaintainstateforashortwhileinordertocleanup
properly.IftheparticularUIallowsfortheusertorejecta
callbeforeitsanswered,a403(Forbidden)isagoodwayto
expressthat.Aspertherulesabove,aBYEcan'tbesent.
15.1TerminatingaSessionwithaBYERequest
15.1.1UACBehavior
ABYErequestisconstructedaswouldanyotherrequestwithina
dialog,asdescribedinSection12.
OncetheBYEisconstructed,theUACcorecreatesanewnon-INVITE
clienttransaction,andpassesittheBYErequest.TheUACMUST
considerthesessionterminated(andthereforestopsendingor
listeningformedia)assoonastheBYErequestispassedtothe
clienttransaction.IftheresponsefortheBYEisa481
(Call/TransactionDoesNotExist)ora408(RequestTimeout)orno
Rosenberg,et.al.StandardsTrack[Page90]
RFC3261SIP:SessionInitiationProtocolJune2002
responseatallisreceivedfortheBYE(thatis,atimeoutis
returnedbytheclienttransaction),theUACMUSTconsiderthe
sessionandthedialogterminated.
15.1.2UASBehavior
AUASfirstprocessestheBYErequestaccordingtothegeneralUAS
processingdescribedinSection8.2.AUAScorereceivingaBYE
requestchecksifitmatchesanexistingdialog.IftheBYEdoesnot
matchanexistingdialog,theUAScoreSHOULDgeneratea481
(Call/TransactionDoesNotExist)responseandpassthattothe
servertransaction.
ThisrulemeansthataBYEsentwithouttagsbyaUACwillbe
rejected.ThisisachangefromRFC2543,whichallowedBYE
withouttags.
AUAScorereceivingaBYErequestforanexistingdialogMUSTfollow
theproceduresofSection12.2.2toprocesstherequest.Oncedone,
theUASSHOULDterminatethesession(andthereforestopsendingand
listeningformedia).Theonlycasewhereitcanelectnottoare
multicastsessions,whereparticipationispossibleeveniftheother
participantinthedialoghasterminateditsinvolvementinthe
session.Whetherornotitendsitsparticipationonthesession,
theUAScoreMUSTgeneratea2xxresponsetotheBYE,andMUSTpass
thattotheservertransactionfortransmission.
TheUASMUSTstillrespondtoanypendingrequestsreceivedforthat
dialog.ItisRECOMMENDEDthata487(RequestTerminated)response
begeneratedtothosependingrequests.
16ProxyBehavior
16.1Overview
SIPproxiesareelementsthatrouteSIPrequeststouseragent
serversandSIPresponsestouseragentclients.Arequestmay
traverseseveralproxiesonitswaytoaUAS.Eachwillmakerouting
decisions,modifyingtherequestbeforeforwardingittothenext
element.Responseswillroutethroughthesamesetofproxies
traversedbytherequestinthereverseorder.
BeingaproxyisalogicalroleforaSIPelement.Whenarequest
arrives,anelementthatcanplaytheroleofaproxyfirstdecides
ifitneedstorespondtotherequestonitsown.Forinstance,the
requestmaybemalformedortheelementmayneedcredentialsfromthe
clientbeforeactingasaproxy.TheelementMAYrespondwithany
Rosenberg,et.al.StandardsTrack[Page91]
RFC3261SIP:SessionInitiationProtocolJune2002
appropriateerrorcode.Whenrespondingdirectlytoarequest,the
elementisplayingtheroleofaUASandMUSTbehaveasdescribedin
Section8.2.
Aproxycanoperateineitherastatefulorstatelessmodeforeach
newrequest.Whenstateless,aproxyactsasasimpleforwarding
element.Itforwardseachrequestdownstreamtoasingleelement
determinedbymakingatargetingandroutingdecisionbasedonthe
request.Itsimplyforwardseveryresponseitreceivesupstream.A
statelessproxydiscardsinformationaboutamessageoncethemessage
hasbeenforwarded.Astatefulproxyremembersinformation
(specifically,transactionstate)abouteachincomingrequestandany
requestsitsendsasaresultofprocessingtheincomingrequest.It
usesthisinformationtoaffecttheprocessingoffuturemessages
associatedwiththatrequest.AstatefulproxyMAYchooseto"fork"
arequest,routingittomultipledestinations.Anyrequestthatis
forwardedtomorethanonelocationMUSTbehandledstatefully.
Insomecircumstances,aproxyMAYforwardrequestsusingstateful
transports(suchasTCP)withoutbeingtransaction-stateful.For
instance,aproxyMAYforwardarequestfromoneTCPconnectionto
anothertransactionstatelesslyaslongasitplacesenough
informationinthemessagetobeabletoforwardtheresponsedown
thesameconnectiontherequestarrivedon.Requestsforwarded
betweendifferenttypesoftransportswheretheproxy'sTUmusttake
anactiveroleinensuringreliabledeliveryononeofthetransports
MUSTbeforwardedtransactionstatefully.
AstatefulproxyMAYtransitiontostatelessoperationatanytime
duringtheprocessingofarequest,solongasitdidnotdoanything
thatwouldotherwisepreventitfrombeingstatelessinitially
(forking,forexample,orgenerationofa100response).When
performingsuchatransition,allstateissimplydiscarded.The
proxySHOULDNOTinitiateaCANCELrequest.
Muchoftheprocessinginvolvedwhenactingstatelesslyorstatefully
forarequestisidentical.Thenextseveralsubsectionsarewritten
fromthepointofviewofastatefulproxy.Thelastsectioncalls
outthoseplaceswhereastatelessproxybehavesdifferently.
16.2StatefulProxy
Whenstateful,aproxyispurelyaSIPtransactionprocessingengine.
Itsbehaviorismodeledhereintermsoftheserverandclient
transactionsdefinedinSection17.Astatefulproxyhasaserver
transactionassociatedwithoneormoreclienttransactionsbya
higherlayerproxyprocessingcomponent(seefigure3),knownasa
proxycore.Anincomingrequestisprocessedbyaserver
Rosenberg,et.al.StandardsTrack[Page92]
RFC3261SIP:SessionInitiationProtocolJune2002
transaction.Requestsfromtheservertransactionarepassedtoa
proxycore.Theproxycoredetermineswheretoroutetherequest,
choosingoneormorenext-hoplocations.Anoutgoingrequestfor
eachnext-hoplocationisprocessedbyitsownassociatedclient
transaction.Theproxycorecollectstheresponsesfromtheclient
transactionsandusesthemtosendresponsestotheserver
transaction.
Astatefulproxycreatesanewservertransactionforeachnew
requestreceived.Anyretransmissionsoftherequestwillthenbe
handledbythatservertransactionperSection17.Theproxycore
MUSTbehaveasaUASwithrespecttosendinganimmediateprovisional
onthatservertransaction(suchas100Trying)asdescribedin
Section8.2.6.Thus,astatefulproxySHOULDNOTgenerate100
(Trying)responsestonon-INVITErequests.
Thisisamodelofproxybehavior,notofsoftware.An
implementationisfreetotakeanyapproachthatreplicatesthe
externalbehaviorthismodeldefines.
Forallnewrequests,includinganywithunknownmethods,anelement
intendingtoproxytherequestMUST:
1.Validatetherequest(Section16.3)
2.Preprocessroutinginformation(Section16.4)
3.Determinetarget(s)fortherequest(Section16.5)
+--------------------+
||+---+
|||C|
|||T|
||+---+
+---+|Proxy|+---+CT=ClientTransaction
|S||"Higher"Layer||C|
|T||||T|ST=ServerTransaction
+---+||+---+
||+---+
|||C|
|||T|
||+---+
+--------------------+
Figure3:StatefulProxyModel
Rosenberg,et.al.StandardsTrack[Page93]
RFC3261SIP:SessionInitiationProtocolJune2002
4.Forwardtherequesttoeachtarget(Section16.6)
5.Processallresponses(Section16.7)
16.3RequestValidation
Beforeanelementcanproxyarequest,itMUSTverifythemessage's
validity.Avalidmessagemustpassthefollowingchecks:
1.ReasonableSyntax
2.URIscheme
3.Max-Forwards
4.(Optional)LoopDetection
5.Proxy-Require
6.Proxy-Authorization
Ifanyofthesechecksfail,theelementMUSTbehaveasauseragent
server(seeSection8.2)andrespondwithanerrorcode.
Noticethataproxyisnotrequiredtodetectmergedrequestsand
MUSTNOTtreatmergedrequestsasanerrorcondition.Theendpoints
receivingtherequestswillresolvethemergeasdescribedinSection
8.2.2.2.
1.Reasonablesyntaxcheck
TherequestMUSTbewell-formedenoughtobehandledwithaserver
transaction.Anycomponentsinvolvedintheremainderofthese
RequestValidationstepsortheRequestForwardingsectionMUSTbe
well-formed.Anyothercomponents,well-formedornot,SHOULDbe
ignoredandremainunchangedwhenthemessageisforwarded.For
instance,anelementwouldnotrejectarequestbecauseofa
malformedDateheaderfield.Likewise,aproxywouldnotremovea
malformedDateheaderfieldbeforeforwardingarequest.
Thisprotocolisdesignedtobeextended.Futureextensionsmay
definenewmethodsandheaderfieldsatanytime.AnelementMUST
NOTrefusetoproxyarequestbecauseitcontainsamethodor
headerfielditdoesnotknowabout.
Rosenberg,et.al.StandardsTrack[Page94]
RFC3261SIP:SessionInitiationProtocolJune2002
2.URIschemecheck
IftheRequest-URIhasaURIwhoseschemeisnotunderstoodbythe
proxy,theproxySHOULDrejecttherequestwitha416(Unsupported
URIScheme)response.
3.Max-Forwardscheck
TheMax-Forwardsheaderfield(Section20.22)isusedtolimitthe
numberofelementsaSIPrequestcantraverse.
IftherequestdoesnotcontainaMax-Forwardsheaderfield,this
checkispassed.
IftherequestcontainsaMax-Forwardsheaderfieldwithafield
valuegreaterthanzero,thecheckispassed.
IftherequestcontainsaMax-Forwardsheaderfieldwithafield
valueofzero(0),theelementMUSTNOTforwardtherequest.If
therequestwasforOPTIONS,theelementMAYactasthefinal
recipientandrespondperSection11.Otherwise,theelementMUST
returna483(Toomanyhops)response.
4.OptionalLoopDetectioncheck
AnelementMAYcheckforforwardingloopsbeforeforwardinga
request.IftherequestcontainsaViaheaderfieldwithasent-
byvaluethatequalsavalueplacedintopreviousrequestsbythe
proxy,therequesthasbeenforwardedbythiselementbefore.The
requesthaseitherloopedorislegitimatelyspiralingthroughthe
element.Todetermineiftherequesthaslooped,theelementMAY
performthebranchparametercalculationdescribedinStep8of
Section16.6onthismessageandcompareittotheparameter
receivedinthatViaheaderfield.Iftheparametersmatch,the
requesthaslooped.Iftheydiffer,therequestisspiraling,and
processingcontinues.Ifaloopisdetected,theelementMAY
returna482(LoopDetected)response.
5.Proxy-Requirecheck
Futureextensionstothisprotocolmayintroducefeaturesthat
requirespecialhandlingbyproxies.Endpointswillincludea
Proxy-Requireheaderfieldinrequeststhatusethesefeatures,
tellingtheproxynottoprocesstherequestunlessthefeatureis
understood.
Rosenberg,et.al.StandardsTrack[Page95]
RFC3261SIP:SessionInitiationProtocolJune2002
IftherequestcontainsaProxy-Requireheaderfield(Section
20.29)withoneormoreoption-tagsthiselementdoesnot
understand,theelementMUSTreturna420(BadExtension)
response.TheresponseMUSTincludeanUnsupported(Section
20.40)headerfieldlistingthoseoption-tagstheelementdidnot
understand.
6.Proxy-Authorizationcheck
Ifanelementrequirescredentialsbeforeforwardingarequest,
therequestMUSTbeinspectedasdescribedinSection22.3.That
sectionalsodefineswhattheelementmustdoiftheinspection
fails.
16.4RouteInformationPreprocessing
TheproxyMUSTinspecttheRequest-URIoftherequest.Ifthe
Request-URIoftherequestcontainsavaluethisproxypreviously
placedintoaRecord-Routeheaderfield(seeSection16.6item4),
theproxyMUSTreplacetheRequest-URIintherequestwiththelast
valuefromtheRouteheaderfield,andremovethatvaluefromthe
Routeheaderfield.TheproxyMUSTthenproceedasifitreceived
thismodifiedrequest.
Thiswillonlyhappenwhentheelementsendingtherequesttothe
proxy(whichmayhavebeenanendpoint)isastrictrouter.This
rewriteonreceiveisnecessarytoenablebackwardscompatibility
withthoseelements.Italsoallowselementsfollowingthis
specificationtopreservetheRequest-URIthroughstrict-routing
proxies(seeSection12.2.1.1).
Thisrequirementdoesnotobligateaproxytokeepstateinorder
todetectURIsitpreviouslyplacedinRecord-Routeheaderfields.
Instead,aproxyneedonlyplaceenoughinformationinthoseURIs
torecognizethemasvaluesitprovidedwhentheylaterappear.
IftheRequest-URIcontainsamaddrparameter,theproxyMUSTcheck
toseeifitsvalueisinthesetofaddressesordomainstheproxy
isconfiguredtoberesponsiblefor.IftheRequest-URIhasamaddr
parameterwithavaluetheproxyisresponsiblefor,andtherequest
wasreceivedusingtheportandtransportindicated(explicitlyorby
default)intheRequest-URI,theproxyMUSTstripthemaddrandany
non-defaultportortransportparameterandcontinueprocessingasif
thosevalueshadnotbeenpresentintherequest.
Rosenberg,et.al.StandardsTrack[Page96]
RFC3261SIP:SessionInitiationProtocolJune2002
Arequestmayarrivewithamaddrmatchingtheproxy,butona
portortransportdifferentfromthatindicatedintheURI.Such
arequestneedstobeforwardedtotheproxyusingtheindicated
portandtransport.
IfthefirstvalueintheRouteheaderfieldindicatesthisproxy,
theproxyMUSTremovethatvaluefromtherequest.
16.5DeterminingRequestTargets
Next,theproxycalculatesthetarget(s)oftherequest.Thesetof
targetswilleitherbepredeterminedbythecontentsoftherequest
orwillbeobtainedfromanabstractlocationservice.Eachtarget
inthesetisrepresentedasaURI.
IftheRequest-URIoftherequestcontainsanmaddrparameter,the
Request-URIMUSTbeplacedintothetargetsetastheonlytarget
URI,andtheproxyMUSTproceedtoSection16.6.
IfthedomainoftheRequest-URIindicatesadomainthiselementis
notresponsiblefor,theRequest-URIMUSTbeplacedintothetarget
setastheonlytarget,andtheelementMUSTproceedtothetaskof
RequestForwarding(Section16.6).
Therearemanycircumstancesinwhichaproxymightreceivea
requestforadomainitisnotresponsiblefor.Afirewallproxy
handlingoutgoingcalls(thewayHTTPproxieshandleoutgoing
requests)isanexampleofwherethisislikelytooccur.
Ifthetargetsetfortherequesthasnotbeenpredeterminedas
describedabove,thisimpliesthattheelementisresponsibleforthe
domainintheRequest-URI,andtheelementMAYusewhatevermechanism
itdesirestodeterminewheretosendtherequest.Anyofthese
mechanismscanbemodeledasaccessinganabstractLocationService.
Thismayconsistofobtaininginformationfromalocationservice
createdbyaSIPRegistrar,readingadatabase,consultingapresence
server,utilizingotherprotocols,orsimplyperformingan
algorithmicsubstitutionontheRequest-URI.Whenaccessingthe
locationserviceconstructedbyaregistrar,theRequest-URIMUST
firstbecanonicalizedasdescribedinSection10.3beforebeingused
asanindex.Theoutputofthesemechanismsisusedtoconstructthe
targetset.
IftheRequest-URIdoesnotprovidesufficientinformationforthe
proxytodeterminethetargetset,itSHOULDreturna485(Ambiguous)
response.ThisresponseSHOULDcontainaContactheaderfield
containingURIsofnewaddressestobetried.Forexample,anINVITE
Rosenberg,et.al.StandardsTrack[Page97]
RFC3261SIP:SessionInitiationProtocolJune2002
tosip:[email protected]
locationservicehasmultipleJohnSmithslisted.SeeSection
21.4.23fordetails.
Anyinformationinorabouttherequestorthecurrentenvironmentof
theelementMAYbeusedintheconstructionofthetargetset.For
instance,differentsetsmaybeconstructeddependingoncontentsor
thepresenceofheaderfieldsandbodies,thetimeofdayofthe
request'sarrival,theinterfaceonwhichtherequestarrived,
failureofpreviousrequests,oreventheelement'scurrentlevelof
utilization.
Aspotentialtargetsarelocatedthroughtheseservices,theirURIs
areaddedtothetargetset.Targetscanonlybeplacedinthe
targetsetonce.IfatargetURIisalreadypresentintheset
(basedonthedefinitionofequalityfortheURItype),itMUSTNOT
beaddedagain.
AproxyMUSTNOTaddadditionaltargetstothetargetsetifthe
Request-URIoftheoriginalrequestdoesnotindicatearesourcethis
proxyisresponsiblefor.
AproxycanonlychangetheRequest-URIofarequestduring
forwardingifitisresponsibleforthatURI.Iftheproxyisnot
responsibleforthatURI,itwillnotrecurseon3xxor416
responsesasdescribedbelow.
IftheRequest-URIoftheoriginalrequestindicatesaresourcethis
proxyisresponsiblefor,theproxyMAYcontinuetoaddtargetsto
thesetafterbeginningRequestForwarding.ItMAYuseany
informationobtainedduringthatprocessingtodeterminenewtargets.
Forinstance,aproxymaychoosetoincorporatecontactsobtainedin
aredirectresponse(3xx)intothetargetset.Ifaproxyusesa
dynamicsourceofinformationwhilebuildingthetargetset(for
instance,ifitconsultsaSIPRegistrar),itSHOULDmonitorthat
sourceforthedurationofprocessingtherequest.Newlocations
SHOULDbeaddedtothetargetsetastheybecomeavailable.As
above,anygivenURIMUSTNOTbeaddedtothesetmorethanonce.
AllowingaURItobeaddedtothesetonlyoncereduces
unnecessarynetworktraffic,andinthecaseofincorporating
contactsfromredirectrequestspreventsinfiniterecursion.
Forexample,atriviallocationserviceisa"no-op",wherethe
targetURIisequaltotheincomingrequestURI.Therequestissent
toaspecificnexthopproxyforfurtherprocessing.Duringrequest
Rosenberg,et.al.StandardsTrack[Page98]
RFC3261SIP:SessionInitiationProtocolJune2002
forwardingofSection16.6,Item6,theidentityofthatnexthop,
expressedasaSIPorSIPSURI,isinsertedasthetop-mostRoute
headerfieldvalueintotherequest.
IftheRequest-URIindicatesaresourceatthisproxythatdoesnot
exist,theproxyMUSTreturna404(NotFound)response.
Ifthetargetsetremainsemptyafterapplyingalloftheabove,the
proxyMUSTreturnanerrorresponse,whichSHOULDbethe480
(TemporarilyUnavailable)response.
16.6RequestForwarding
Assoonasthetargetsetisnon-empty,aproxyMAYbeginforwarding
therequest.AstatefulproxyMAYprocessthesetinanyorder.It
MAYprocessmultipletargetsserially,allowingeachclient
transactiontocompletebeforestartingthenext.ItMAYstart
clienttransactionswitheverytargetinparallel.ItalsoMAY
arbitrarilydividethesetintogroups,processingthegroups
seriallyandprocessingthetargetsineachgroupinparallel.
Acommonorderingmechanismistousetheqvalueparameteroftargets
obtainedfromContactheaderfields(seeSection20.10).Targetsare
processedfromhighestqvaluetolowest.Targetswithequalqvalues
maybeprocessedinparallel.
Astatefulproxymusthaveamechanismtomaintainthetargetsetas
responsesarereceivedandassociatetheresponsestoeachforwarded
requestwiththeoriginalrequest.Forthepurposesofthismodel,
thismechanismisa"responsecontext"createdbytheproxylayer
beforeforwardingthefirstrequest.
Foreachtarget,theproxyforwardstherequestfollowingthese
steps:
1.Makeacopyofthereceivedrequest
2.UpdatetheRequest-URI
3.UpdatetheMax-Forwardsheaderfield
4.OptionallyaddaRecord-routeheaderfieldvalue
5.Optionallyaddadditionalheaderfields
6.Postprocessroutinginformation
7.Determinethenext-hopaddress,port,andtransport
Rosenberg,et.al.StandardsTrack[Page99]
RFC3261SIP:SessionInitiationProtocolJune2002
8.AddaViaheaderfieldvalue
9.AddaContent-Lengthheaderfieldifnecessary
10.Forwardthenewrequest
11.SettimerC
Eachofthesestepsisdetailedbelow:
1.Copyrequest
Theproxystartswithacopyofthereceivedrequest.Thecopy
MUSTinitiallycontainalloftheheaderfieldsfromthe
receivedrequest.Fieldsnotdetailedintheprocessing
describedbelowMUSTNOTberemoved.ThecopySHOULDmaintain
theorderingoftheheaderfieldsasinthereceivedrequest.
TheproxyMUSTNOTreorderfieldvalueswithacommonfield
name(SeeSection7.3.1).TheproxyMUSTNOTaddto,modify,
orremovethemessagebody.
Anactualimplementationneednotperformacopy;theprimary
requirementisthattheprocessingforeachnexthopbeginwith
thesamerequest.
2.Request-URI
TheRequest-URIinthecopy'sstartlineMUSTbereplacedwith
theURIforthistarget.IftheURIcontainsanyparameters
notallowedinaRequest-URI,theyMUSTberemoved.
Thisistheessenceofaproxy'srole.Thisisthemechanism
throughwhichaproxyroutesarequesttowarditsdestination.
Insomecircumstances,thereceivedRequest-URIisplacedinto
thetargetsetwithoutbeingmodified.Forthattarget,the
replacementaboveiseffectivelyano-op.
3.Max-Forwards
IfthecopycontainsaMax-Forwardsheaderfield,theproxy
MUSTdecrementitsvaluebyone(1).
IfthecopydoesnotcontainaMax-Forwardsheaderfield,the
proxyMUSTaddonewithafieldvalue,whichSHOULDbe70.
SomeexistingUAswillnotprovideaMax-Forwardsheaderfield
inarequest.
Rosenberg,et.al.StandardsTrack[Page100]
RFC3261SIP:SessionInitiationProtocolJune2002
4.Record-Route
Ifthisproxywishestoremainonthepathoffuturerequests
inadialogcreatedbythisrequest(assumingtherequest
createsadialog),itMUSTinsertaRecord-Routeheaderfield
valueintothecopybeforeanyexistingRecord-Routeheader
fieldvalues,evenifaRouteheaderfieldisalreadypresent.
RequestsestablishingadialogmaycontainapreloadedRoute
headerfield.
Ifthisrequestisalreadypartofadialog,theproxySHOULD
insertaRecord-Routeheaderfieldvalueifitwishestoremain
onthepathoffuturerequestsinthedialog.Innormal
endpointoperationasdescribedinSection12,theseRecord-
Routeheaderfieldvalueswillnothaveanyeffectontheroute
setsusedbytheendpoints.
Theproxywillremainonthepathifitchoosestonotinserta
Record-Routeheaderfieldvalueintorequeststhatarealready
partofadialog.However,itwouldberemovedfromthepath
whenanendpointthathasfailedreconstitutesthedialog.
AproxyMAYinsertaRecord-Routeheaderfieldvalueintoany
request.Iftherequestdoesnotinitiateadialog,the
endpointswillignorethevalue.SeeSection12fordetailson
howendpointsusetheRecord-Routeheaderfieldvaluesto
constructRouteheaderfields.
Eachproxyinthepathofarequestchooseswhethertoadda
Record-Routeheaderfieldvalueindependently-thepresenceof
aRecord-Routeheaderfieldinarequestdoesnotobligatethis
proxytoaddavalue.
TheURIplacedintheRecord-RouteheaderfieldvalueMUSTbea
SIPorSIPSURI.ThisURIMUSTcontainanlrparameter(see
Section19.1.1).ThisURIMAYbedifferentforeach
destinationtherequestisforwardedto.TheURISHOULDNOT
containthetransportparameterunlesstheproxyhasknowledge
(suchasinaprivatenetwork)thatthenextdownstreamelement
thatwillbeinthepathofsubsequentrequestssupportsthat
transport.
TheURIthisproxyprovideswillbeusedbysomeotherelement
tomakearoutingdecision.Thisproxy,ingeneral,hasnoway
ofknowingthecapabilitiesofthatelement,soitmust
restrictitselftothemandatoryelementsofaSIP
implementation:SIPURIsandeithertheTCPorUDPtransports.
Rosenberg,et.al.StandardsTrack[Page101]
RFC3261SIP:SessionInitiationProtocolJune2002
TheURIplacedintheRecord-RouteheaderfieldMUSTresolveto
theelementinsertingit(orasuitablestand-in)whenthe
serverlocationproceduresof[4]areappliedtoit,sothat
subsequentrequestsreachthesameSIPelement.Ifthe
Request-URIcontainsaSIPSURI,orthetopmostRouteheader
fieldvalue(afterthepostprocessingofbullet6)containsa
SIPSURI,theURIplacedintotheRecord-Routeheaderfield
MUSTbeaSIPSURI.Furthermore,iftherequestwasnot
receivedoverTLS,theproxyMUSTinsertaRecord-Routeheader
field.Inasimilarfashion,aproxythatreceivesarequest
overTLS,butgeneratesarequestwithoutaSIPSURIinthe
Request-URIortopmostRouteheaderfieldvalue(afterthepost
processingofbullet6),MUSTinsertaRecord-Routeheader
fieldthatisnotaSIPSURI.
Aproxyatasecurityperimetermustremainontheperimeter
throughoutthedialog.
IftheURIplacedintheRecord-Routeheaderfieldneedstobe
rewrittenwhenitpassesbackthroughinaresponse,theURI
MUSTbedistinctenoughtolocateatthattime.(Therequest
mayspiralthroughthisproxy,resultinginmorethanone
Record-Routeheaderfieldvaluebeingadded).Item8of
Section16.7recommendsamechanismtomaketheURI
sufficientlydistinct.
TheproxyMAYincludeparametersintheRecord-Routeheader
fieldvalue.Thesewillbeechoedinsomeresponsestothe
requestsuchasthe200(OK)responsestoINVITE.Such
parametersmaybeusefulforkeepingstateinthemessage
ratherthantheproxy.
Ifaproxyneedstobeinthepathofanytypeofdialog(such
asonestraddlingafirewall),itSHOULDaddaRecord-Route
headerfieldvaluetoeveryrequestwithamethoditdoesnot
understandsincethatmethodmayhavedialogsemantics.
TheURIaproxyplacesintoaRecord-Routeheaderfieldisonly
validforthelifetimeofanydialogcreatedbythetransaction
inwhichitoccurs.Adialog-statefulproxy,forexample,MAY
refusetoacceptfuturerequestswiththatvalueinthe
Request-URIafterthedialoghasterminated.Non-dialog-
statefulproxies,ofcourse,havenoconceptofwhenthedialog
hasterminated,buttheyMAYencodeenoughinformationinthe
valuetocompareitagainstthedialogidentifieroffuture
requestsandMAYrejectrequestsnotmatchingthatinformation.
EndpointsMUSTNOTuseaURIobtainedfromaRecord-Route
headerfieldoutsidethedialoginwhichitwasprovided.See
Rosenberg,et.al.StandardsTrack[Page102]
RFC3261SIP:SessionInitiationProtocolJune2002
Section12formoreinformationonanendpoint'suseof
Record-Routeheaderfields.
Record-routingmayberequiredbycertainserviceswherethe
proxyneedstoobserveallmessagesinadialog.However,it
slowsdownprocessingandimpairsscalabilityandthusproxies
shouldonlyrecord-routeifrequiredforaparticularservice.
TheRecord-RouteprocessisdesignedtoworkforanySIP
requestthatinitiatesadialog.INVITEistheonlysuch
requestinthisspecification,butextensionstotheprotocol
MAYdefineothers.
5.AddAdditionalHeaderFields
TheproxyMAYaddanyotherappropriateheaderfieldstothe
copyatthispoint.
6.Postprocessroutinginformation
AproxyMAYhavealocalpolicythatmandatesthatarequest
visitaspecificsetofproxiesbeforebeingdeliveredtothe
destination.AproxyMUSTensurethatallsuchproxiesare
looserouters.Generally,thiscanonlybeknownwith
certaintyiftheproxiesarewithinthesameadministrative
domain.ThissetofproxiesisrepresentedbyasetofURIs
(eachofwhichcontainsthelrparameter).ThissetMUSTbe
pushedintotheRouteheaderfieldofthecopyaheadofany
existingvalues,ifpresent.IftheRouteheaderfieldis
absent,itMUSTbeadded,containingthatlistofURIs.
Iftheproxyhasalocalpolicythatmandatesthattherequest
visitonespecificproxy,analternativetopushingaRoute
valueintotheRouteheaderfieldistobypasstheforwarding
logicofitem10below,andinsteadjustsendtherequestto
theaddress,port,andtransportforthatspecificproxy.If
therequesthasaRouteheaderfield,thisalternativeMUSTNOT
beusedunlessitisknownthatnexthopproxyisaloose
router.Otherwise,thisapproachMAYbeused,buttheRoute
insertionmechanismaboveispreferredforitsrobustness,
flexibility,generalityandconsistencyofoperation.
Furthermore,iftheRequest-URIcontainsaSIPSURI,TLSMUST
beusedtocommunicatewiththatproxy.
IfthecopycontainsaRouteheaderfield,theproxyMUST
inspecttheURIinitsfirstvalue.IfthatURIdoesnot
containanlrparameter,theproxyMUSTmodifythecopyas
follows:
Rosenberg,et.al.StandardsTrack[Page103]
RFC3261SIP:SessionInitiationProtocolJune2002
-TheproxyMUSTplacetheRequest-URIintotheRouteheader
fieldasthelastvalue.
-TheproxyMUSTthenplacethefirstRouteheaderfieldvalue
intotheRequest-URIandremovethatvaluefromtheRoute
headerfield.
AppendingtheRequest-URItotheRouteheaderfieldispartof
amechanismusedtopasstheinformationinthatRequest-URI
throughstrict-routingelements."Popping"thefirstRoute
headerfieldvalueintotheRequest-URIformatsthemessagethe
wayastrict-routingelementexpectstoreceiveit(withits
ownURIintheRequest-URIandthenextlocationtovisitin
thefirstRouteheaderfieldvalue).
7.DetermineNext-HopAddress,Port,andTransport
TheproxyMAYhavealocalpolicytosendtherequesttoa
specificIPaddress,port,andtransport,independentofthe
valuesoftheRouteandRequest-URI.SuchapolicyMUSTNOTbe
usediftheproxyisnotcertainthattheIPaddress,port,and
transportcorrespondtoaserverthatisalooserouter.
However,thismechanismforsendingtherequestthrougha
specificnexthopisNOTRECOMMENDED;insteadaRouteheader
fieldshouldbeusedforthatpurposeasdescribedabove.
Intheabsenceofsuchanoverridingmechanism,theproxy
appliestheprocedureslistedin[4]asfollowstodetermine
wheretosendtherequest.Iftheproxyhasreformattedthe
requesttosendtoastrict-routingelementasdescribedin
step6above,theproxyMUSTapplythoseprocedurestothe
Request-URIoftherequest.Otherwise,theproxyMUSTapply
theprocedurestothefirstvalueintheRouteheaderfield,if
present,elsetheRequest-URI.Theprocedureswillproducean
orderedsetof(address,port,transport)tuples.
IndependentlyofwhichURIisbeingusedasinputtothe
proceduresof[4],iftheRequest-URIspecifiesaSIPS
resource,theproxyMUSTfollowtheproceduresof[4]asifthe
inputURIwereaSIPSURI.
Asdescribedin[4],theproxyMUSTattempttodeliverthe
messagetothefirsttupleinthatset,andproceedthroughthe
setinorderuntilthedeliveryattemptsucceeds.
Foreachtupleattempted,theproxyMUSTformatthemessageas
appropriateforthetupleandsendtherequestusinganew
clienttransactionasdetailedinsteps8through10.
Rosenberg,et.al.StandardsTrack[Page104]
RFC3261SIP:SessionInitiationProtocolJune2002
Sinceeachattemptusesanewclienttransaction,itrepresents
anewbranch.Thus,thebranchparameterprovidedwiththeVia
headerfieldinsertedinstep8MUSTbedifferentforeach
attempt.
Iftheclienttransactionreportsfailuretosendtherequest
oratimeoutfromitsstatemachine,theproxycontinuestothe
nextaddressinthatorderedset.Iftheorderedsetis
exhausted,therequestcannotbeforwardedtothiselementin
thetargetset.Theproxydoesnotneedtoplaceanythingin
theresponsecontext,butotherwiseactsasifthiselementof
thetargetsetreturneda408(RequestTimeout)finalresponse.
8.AddaViaheaderfieldvalue
TheproxyMUSTinsertaViaheaderfieldvalueintothecopy
beforetheexistingViaheaderfieldvalues.Theconstruction
ofthisvaluefollowsthesameguidelinesofSection8.1.1.7.
Thisimpliesthattheproxywillcomputeitsownbranch
parameter,whichwillbegloballyuniqueforthatbranch,and
containtherequisitemagiccookie.Notethatthisimpliesthat
thebranchparameterwillbedifferentfordifferentinstances
ofaspiraledorloopedrequestthroughaproxy.
Proxieschoosingtodetectloopshaveanadditionalconstraint
inthevaluetheyuseforconstructionofthebranchparameter.
AproxychoosingtodetectloopsSHOULDcreateabranch
parameterseparableintotwopartsbytheimplementation.The
firstpartMUSTsatisfytheconstraintsofSection8.1.1.7as
describedabove.Thesecondisusedtoperformloopdetection
anddistinguishloopsfromspirals.
Loopdetectionisperformedbyverifyingthat,whenarequest
returnstoaproxy,thosefieldshavinganimpactonthe
processingoftherequesthavenotchanged.Thevalueplaced
inthispartofthebranchparameterSHOULDreflectallof
thosefields(includinganyRoute,Proxy-RequireandProxy-
Authorizationheaderfields).Thisistoensurethatifthe
requestisroutedbacktotheproxyandoneofthosefields
changes,itistreatedasaspiralandnotaloop(seeSection
16.3).Acommonwaytocreatethisvalueistocomputea
cryptographichashoftheTotag,Fromtag,Call-IDheader
field,theRequest-URIoftherequestreceived(before
translation),thetopmostViaheader,andthesequencenumber
fromtheCSeqheaderfield,inadditiontoanyProxy-Require
andProxy-Authorizationheaderfieldsthatmaybepresent.The
Rosenberg,et.al.StandardsTrack[Page105]
RFC3261SIP:SessionInitiationProtocolJune2002
algorithmusedtocomputethehashisimplementation-dependent,
butMD5(RFC1321[35]),expressedinhexadecimal,isa
reasonablechoice.(Base64isnotpermissibleforatoken.)
Ifaproxywishestodetectloops,the"branch"parameterit
suppliesMUSTdependonallinformationaffectingprocessingof
arequest,includingtheincomingRequest-URIandanyheader
fieldsaffectingtherequest'sadmissionorrouting.Thisis
necessarytodistinguishloopedrequestsfromrequestswhose
routingparametershavechangedbeforereturningtothis
server.
TherequestmethodMUSTNOTbeincludedinthecalculationof
thebranchparameter.Inparticular,CANCELandACKrequests
(fornon-2xxresponses)MUSThavethesamebranchvalueasthe
correspondingrequesttheycanceloracknowledge.Thebranch
parameterisusedincorrelatingthoserequestsattheserver
handlingthem(seeSections17.2.3and9.2).
9.AddaContent-Lengthheaderfieldifnecessary
Iftherequestwillbesenttothenexthopusingastream-
basedtransportandthecopycontainsnoContent-Lengthheader
field,theproxyMUSTinsertonewiththecorrectvalueforthe
bodyoftherequest(seeSection20.14).
10.ForwardRequest
AstatefulproxyMUSTcreateanewclienttransactionforthis
requestasdescribedinSection17.1andinstructsthe
transactiontosendtherequestusingtheaddress,portand
transportdeterminedinstep7.
11.SettimerC
InordertohandlethecasewhereanINVITErequestnever
generatesafinalresponse,theTUusesatimerwhichiscalled
timerC.TimerCMUSTbesetforeachclienttransactionwhen
anINVITErequestisproxied.ThetimerMUSTbelargerthan3
minutes.Section16.7bullet2discusseshowthistimeris
updatedwithprovisionalresponses,andSection16.8discusses
processingwhenitfires.
Rosenberg,et.al.StandardsTrack[Page106]
RFC3261SIP:SessionInitiationProtocolJune2002
16.7ResponseProcessing
Whenaresponseisreceivedbyanelement,itfirsttriestolocatea
clienttransaction(Section17.1.3)matchingtheresponse.Ifnone
isfound,theelementMUSTprocesstheresponse(evenifitisan
informationalresponse)asastatelessproxy(describedbelow).Ifa
matchisfound,theresponseishandedtotheclienttransaction.
Forwardingresponsesforwhichaclienttransaction(ormore
generallyanyknowledgeofhavingsentanassociatedrequest)is
notfoundimprovesrobustness.Inparticular,itensuresthat
"late"2xxresponsestoINVITErequestsareforwardedproperly.
Asclienttransactionspassresponsestotheproxylayer,the
followingprocessingMUSTtakeplace:
1.Findtheappropriateresponsecontext
2.UpdatetimerCforprovisionalresponses
3.RemovethetopmostVia
4.Addtheresponsetotheresponsecontext
5.Checktoseeifthisresponseshouldbeforwardedimmediately
6.Whennecessary,choosethebestfinalresponsefromthe
responsecontext
Ifnofinalresponsehasbeenforwardedaftereveryclient
transactionassociatedwiththeresponsecontexthasbeenterminated,
theproxymustchooseandforwardthe"best"responsefromthoseit
hasseensofar.
ThefollowingprocessingMUSTbeperformedoneachresponsethatis
forwarded.Itislikelythatmorethanoneresponsetoeachrequest
willbeforwarded:atleasteachprovisionalandonefinalresponse.
7.Aggregateauthorizationheaderfieldvaluesifnecessary
8.OptionallyrewriteRecord-Routeheaderfieldvalues
9.Forwardtheresponse
10.GenerateanynecessaryCANCELrequests
Rosenberg,et.al.StandardsTrack[Page107]
RFC3261SIP:SessionInitiationProtocolJune2002
Eachoftheabovestepsaredetailedbelow:
1.FindContext
Theproxylocatesthe"responsecontext"itcreatedbefore
forwardingtheoriginalrequestusingthekeydescribedin
Section16.6.Theremainingprocessingstepstakeplacein
thiscontext.
2.UpdatetimerCforprovisionalresponses
ForanINVITEtransaction,iftheresponseisaprovisional
responsewithstatuscodes101to199inclusive(i.e.,anything
but100),theproxyMUSTresettimerCforthatclient
transaction.ThetimerMAYberesettoadifferentvalue,but
thisvalueMUSTbegreaterthan3minutes.
3.Via
TheproxyremovesthetopmostViaheaderfieldvaluefromthe
response.
IfnoViaheaderfieldvaluesremainintheresponse,the
responsewasmeantforthiselementandMUSTNOTbeforwarded.
Theremainderoftheprocessingdescribedinthissectionis
notperformedonthismessage,theUACprocessingrules
describedinSection8.1.3arefollowedinstead(transport
layerprocessinghasalreadyoccurred).
Thiswillhappen,forinstance,whentheelementgenerates
CANCELrequestsasdescribedinSection10.
4.Addresponsetocontext
Finalresponsesreceivedarestoredintheresponsecontext
untilafinalresponseisgeneratedontheservertransaction
associatedwiththiscontext.Theresponsemaybeacandidate
forthebestfinalresponsetobereturnedonthatserver
transaction.Informationfromthisresponsemaybeneededin
formingthebestresponse,evenifthisresponseisnotchosen.
Iftheproxychoosestorecurseonanycontactsina3xx
responsebyaddingthemtothetargetset,itMUSTremovethem
fromtheresponsebeforeaddingtheresponsetotheresponse
context.However,aproxySHOULDNOTrecursetoanon-SIPSURI
iftheRequest-URIoftheoriginalrequestwasaSIPSURI.If
Rosenberg,et.al.StandardsTrack[Page108]
RFC3261SIP:SessionInitiationProtocolJune2002
theproxyrecursesonallofthecontactsina3xxresponse,
theproxySHOULDNOTaddtheresultingcontactlessresponseto
theresponsecontext.
Removingthecontactbeforeaddingtheresponsetotheresponse
contextpreventsthenextelementupstreamfromretryinga
locationthisproxyhasalreadyattempted.
3xxresponsesmaycontainamixtureofSIP,SIPS,andnon-SIP
URIs.AproxymaychoosetorecurseontheSIPandSIPSURIs
andplacetheremainderintotheresponsecontexttobe
returned,potentiallyinthefinalresponse.
Ifaproxyreceivesa416(UnsupportedURIScheme)responseto
arequestwhoseRequest-URIschemewasnotSIP,butthescheme
intheoriginalreceivedrequestwasSIPorSIPS(thatis,the
proxychangedtheschemefromSIPorSIPStosomethingelse
whenitproxiedarequest),theproxySHOULDaddanewURIto
thetargetset.ThisURISHOULDbeaSIPURIversionofthe
non-SIPURIthatwasjusttried.InthecaseofthetelURL,
thisisaccomplishedbyplacingthetelephone-subscriberpart
ofthetelURLintotheuserpartoftheSIPURI,andsetting
thehostparttothedomainwherethepriorrequestwassent.
SeeSection19.1.6formoredetailonformingSIPURIsfromtel
URLs.
Aswitha3xxresponse,ifaproxy"recurses"onthe416by
tryingaSIPorSIPSURIinstead,the416responseSHOULDNOT
beaddedtotheresponsecontext.
5.Checkresponseforforwarding
Untilafinalresponsehasbeensentontheservertransaction,
thefollowingresponsesMUSTbeforwardedimmediately:
-Anyprovisionalresponseotherthan100(Trying)
-Any2xxresponse
Ifa6xxresponseisreceived,itisnotimmediatelyforwarded,
butthestatefulproxySHOULDcancelallclientpending
transactionsasdescribedinSection10,anditMUSTNOTcreate
anynewbranchesinthiscontext.
ThisisachangefromRFC2543,whichmandatedthattheproxy
wastoforwardthe6xxresponseimmediately.ForanINVITE
transaction,thisapproachhadtheproblemthata2xxresponse
couldarriveonanotherbranch,inwhichcasetheproxywould
Rosenberg,et.al.StandardsTrack[Page109]
RFC3261SIP:SessionInitiationProtocolJune2002
havetoforwardthe2xx.TheresultwasthattheUACcould
receivea6xxresponsefollowedbya2xxresponse,whichshould
neverbeallowedtohappen.Underthenewrules,upon
receivinga6xx,aproxywillissueaCANCELrequest,which
willgenerallyresultin487responsesfromalloutstanding
clienttransactions,andthenatthatpointthe6xxis
forwardedupstream.
Afterafinalresponsehasbeensentontheservertransaction,
thefollowingresponsesMUSTbeforwardedimmediately:
-Any2xxresponsetoanINVITErequest
AstatefulproxyMUSTNOTimmediatelyforwardanyother
responses.Inparticular,astatefulproxyMUSTNOTforward
any100(Trying)response.Thoseresponsesthatarecandidates
forforwardinglaterasthe"best"responsehavebeengathered
asdescribedinstep"AddResponsetoContext".
AnyresponsechosenforimmediateforwardingMUSTbeprocessed
asdescribedinsteps"AggregateAuthorizationHeaderField
Values"through"Record-Route".
Thisstep,combinedwiththenext,ensuresthatastateful
proxywillforwardexactlyonefinalresponsetoanon-INVITE
request,andeitherexactlyonenon-2xxresponseoroneormore
2xxresponsestoanINVITErequest.
6.Choosingthebestresponse
AstatefulproxyMUSTsendafinalresponsetoaresponse
context'sservertransactionifnofinalresponseshavebeen
immediatelyforwardedbytheaboverulesandallclient
transactionsinthisresponsecontexthavebeenterminated.
ThestatefulproxyMUSTchoosethe"best"finalresponseamong
thosereceivedandstoredintheresponsecontext.
Iftherearenofinalresponsesinthecontext,theproxyMUST
senda408(RequestTimeout)responsetotheserver
transaction.
Otherwise,theproxyMUSTforwardaresponsefromtheresponses
storedintheresponsecontext.ItMUSTchoosefromthe6xx
classresponsesifanyexistinthecontext.Ifno6xxclass
responsesarepresent,theproxySHOULDchoosefromthelowest
responseclassstoredintheresponsecontext.TheproxyMAY
selectanyresponsewithinthatchosenclass.TheproxySHOULD
Rosenberg,et.al.StandardsTrack[Page110]
RFC3261SIP:SessionInitiationProtocolJune2002
givepreferencetoresponsesthatprovideinformationaffecting
resubmissionofthisrequest,suchas401,407,415,420,and
484ifthe4xxclassischosen.
Aproxywhichreceivesa503(ServiceUnavailable)response
SHOULDNOTforwarditupstreamunlessitcandeterminethatany
subsequentrequestsitmightproxywillalsogeneratea503.
Inotherwords,forwardinga503meansthattheproxyknowsit
cannotserviceanyrequests,notjusttheonefortheRequest-
URIintherequestwhichgeneratedthe503.Iftheonly
responsethatwasreceivedisa503,theproxySHOULDgenerate
a500responseandforwardthatupstream.
TheforwardedresponseMUSTbeprocessedasdescribedinsteps
"AggregateAuthorizationHeaderFieldValues"through"Record-
Route".
Forexample,ifaproxyforwardedarequestto4locations,and
received503,407,501,and404responses,itmaychooseto
forwardthe407(ProxyAuthenticationRequired)response.
1xxand2xxresponsesmaybeinvolvedintheestablishmentof
dialogs.WhenarequestdoesnotcontainaTotag,theTotag
intheresponseisusedbytheUACtodistinguishmultiple
responsestoadialogcreatingrequest.AproxyMUSTNOT
insertatagintotheToheaderfieldofa1xxor2xxresponse
iftherequestdidnotcontainone.AproxyMUSTNOTmodify
thetagintheToheaderfieldofa1xxor2xxresponse.
SinceaproxymaynotinsertatagintotheToheaderfieldof
a1xxresponsetoarequestthatdidnotcontainone,itcannot
issuenon-100provisionalresponsesonitsown.However,it
canbranchtherequesttoaUASsharingthesameelementasthe
proxy.ThisUAScanreturnitsownprovisionalresponses,
enteringintoanearlydialogwiththeinitiatorofthe
request.TheUASdoesnothavetobeadiscreetprocessfrom
theproxy.ItcouldbeavirtualUASimplementedinthesame
codespaceastheproxy.
3-6xxresponsesaredeliveredhop-by-hop.Whenissuinga3-6xx
response,theelementiseffectivelyactingasaUAS,issuing
itsownresponse,usuallybasedontheresponsesreceivedfrom
downstreamelements.AnelementSHOULDpreservetheTotag
whensimplyforwardinga3-6xxresponsetoarequestthatdid
notcontainaTotag.
AproxyMUSTNOTmodifytheTotaginanyforwardedresponseto
arequestthatcontainsaTotag.
Rosenberg,et.al.StandardsTrack[Page111]
RFC3261SIP:SessionInitiationProtocolJune2002
Whileitmakesnodifferencetotheupstreamelementsifthe
proxyreplacedtheTotaginaforwarded3-6xxresponse,
preservingtheoriginaltagmayassistwithdebugging.
Whentheproxyisaggregatinginformationfromseveral
responses,choosingaTotagfromamongthemisarbitrary,and
generatinganewTotagmaymakedebuggingeasier.This
happens,forinstance,whencombining401(Unauthorized)and
407(ProxyAuthenticationRequired)challenges,orcombining
Contactvaluesfromunencryptedandunauthenticated3xx
responses.
7.AggregateAuthorizationHeaderFieldValues
Iftheselectedresponseisa401(Unauthorized)or407(Proxy
AuthenticationRequired),theproxyMUSTcollectanyWWW-
AuthenticateandProxy-Authenticateheaderfieldvaluesfrom
allother401(Unauthorized)and407(ProxyAuthentication
Required)responsesreceivedsofarinthisresponsecontext
andaddthemtothisresponsewithoutmodificationbefore
forwarding.Theresulting401(Unauthorized)or407(Proxy
AuthenticationRequired)responsecouldhaveseveralWWW-
AuthenticateANDProxy-Authenticateheaderfieldvalues.
Thisisnecessarybecauseanyorallofthedestinationsthe
requestwasforwardedtomayhaverequestedcredentials.The
clientneedstoreceiveallofthosechallengesandsupply
credentialsforeachofthemwhenitretriestherequest.
MotivationforthisbehaviorisprovidedinSection26.
8.Record-Route
IftheselectedresponsecontainsaRecord-Routeheaderfield
valueoriginallyprovidedbythisproxy,theproxyMAYchoose
torewritethevaluebeforeforwardingtheresponse.This
allowstheproxytoprovidedifferentURIsforitselftothe
nextupstreamanddownstreamelements.Aproxymaychooseto
usethismechanismforanyreason.Forinstance,itisuseful
formulti-homedhosts.
IftheproxyreceivedtherequestoverTLS,andsentitout
overanon-TLSconnection,theproxyMUSTrewritetheURIin
theRecord-RouteheaderfieldtobeaSIPSURI.Iftheproxy
receivedtherequestoveranon-TLSconnection,andsentitout
overTLS,theproxyMUSTrewritetheURIintheRecord-Route
headerfieldtobeaSIPURI.
Rosenberg,et.al.StandardsTrack[Page112]
RFC3261SIP:SessionInitiationProtocolJune2002
ThenewURIprovidedbytheproxyMUSTsatisfythesame
constraintsonURIsplacedinRecord-Routeheaderfieldsin
requests(seeStep4ofSection16.6)withthefollowing
modifications:
TheURISHOULDNOTcontainthetransportparameterunlessthe
proxyhasknowledgethatthenextupstream(asopposedto
downstream)elementthatwillbeinthepathofsubsequent
requestssupportsthattransport.
WhenaproxydoesdecidetomodifytheRecord-Routeheader
fieldintheresponse,oneoftheoperationsitperformsis
locatingtheRecord-Routevaluethatithadinserted.Ifthe
requestspiraled,andtheproxyinsertedaRecord-Routevalue
ineachiterationofthespiral,locatingthecorrectvaluein
theresponse(whichmustbetheproperiterationinthereverse
direction)istricky.Therulesaboverecommendthataproxy
wishingtorewriteRecord-Routeheaderfieldvaluesinsert
sufficientlydistinctURIsintotheRecord-Routeheaderfield
sothattherightonemaybeselectedforrewriting.A
RECOMMENDEDmechanismtoachievethisisfortheproxyto
appendauniqueidentifierfortheproxyinstancetotheuser
portionoftheURI.
Whentheresponsearrives,theproxymodifiesthefirst
Record-Routewhoseidentifiermatchestheproxyinstance.The
modificationresultsinaURIwithoutthispieceofdata
appendedtotheuserportionoftheURI.Uponthenext
iteration,thesamealgorithm(findthetopmostRecord-Route
headerfieldvaluewiththeparameter)willcorrectlyextract
thenextRecord-Routeheaderfieldvalueinsertedbythat
proxy.
Noteveryresponsetoarequesttowhichaproxyaddsa
Record-RouteheaderfieldvaluewillcontainaRecord-Route
headerfield.IftheresponsedoescontainaRecord-Route
headerfield,itwillcontainthevaluetheproxyadded.
9.Forwardresponse
Afterperformingtheprocessingdescribedinsteps"Aggregate
AuthorizationHeaderFieldValues"through"Record-Route",the
proxyMAYperformanyfeaturespecificmanipulationsonthe
selectedresponse.TheproxyMUSTNOTaddto,modify,or
removethemessagebody.Unlessotherwisespecified,theproxy
MUSTNOTremoveanyheaderfieldvaluesotherthantheVia
headerfieldvaluediscussedinSection16.7Item3.In
particular,theproxyMUSTNOTremoveany"received"parameter
Rosenberg,et.al.StandardsTrack[Page113]
RFC3261SIP:SessionInitiationProtocolJune2002
itmayhaveaddedtothenextViaheaderfieldvaluewhile
processingtherequestassociatedwiththisresponse.The
proxyMUSTpasstheresponsetotheservertransaction
associatedwiththeresponsecontext.Thiswillresultinthe
responsebeingsenttothelocationnowindicatedinthe
topmostViaheaderfieldvalue.Iftheservertransactionis
nolongeravailabletohandlethetransmission,theelement
MUSTforwardtheresponsestatelesslybysendingittothe
servertransport.Theservertransactionmightindicate
failuretosendtheresponseorsignalatimeoutinitsstate
machine.Theseerrorswouldbeloggedfordiagnosticpurposes
asappropriate,buttheprotocolrequiresnoremedialaction
fromtheproxy.
TheproxyMUSTmaintaintheresponsecontextuntilallofits
associatedtransactionshavebeenterminated,evenafter
forwardingafinalresponse.
10.GenerateCANCELs
Iftheforwardedresponsewasafinalresponse,theproxyMUST
generateaCANCELrequestforallpendingclienttransactions
associatedwiththisresponsecontext.AproxySHOULDalso
generateaCANCELrequestforallpendingclienttransactions
associatedwiththisresponsecontextwhenitreceivesa6xx
response.Apendingclienttransactionisonethathas
receivedaprovisionalresponse,butnofinalresponse(itis
intheproceedingstate)andhasnothadanassociatedCANCEL
generatedforit.GeneratingCANCELrequestsisdescribedin
Section9.1.
TherequirementtoCANCELpendingclienttransactionsupon
forwardingafinalresponsedoesnotguaranteethatanendpoint
willnotreceivemultiple200(OK)responsestoanINVITE.200
(OK)responsesonmorethanonebranchmaybegeneratedbefore
theCANCELrequestscanbesentandprocessed.Further,itis
reasonabletoexpectthatafutureextensionmayoverridethis
requirementtoissueCANCELrequests.
16.8ProcessingTimerC
IftimerCshouldfire,theproxyMUSTeitherresetthetimerwith
anyvalueitchooses,orterminatetheclienttransaction.Ifthe
clienttransactionhasreceivedaprovisionalresponse,theproxy
MUSTgenerateaCANCELrequestmatchingthattransaction.Ifthe
clienttransactionhasnotreceivedaprovisionalresponse,theproxy
MUSTbehaveasifthetransactionreceiveda408(RequestTimeout)
response.
Rosenberg,et.al.StandardsTrack[Page114]
RFC3261SIP:SessionInitiationProtocolJune2002
Allowingtheproxytoresetthetimerallowstheproxytodynamically
extendthetransaction'slifetimebasedoncurrentconditions(such
asutilization)whenthetimerfires.
16.9HandlingTransportErrors
Ifthetransportlayernotifiesaproxyofanerrorwhenittriesto
forwardarequest(seeSection18.4),theproxyMUSTbehaveasifthe
forwardedrequestreceiveda503(ServiceUnavailable)response.
Iftheproxyisnotifiedofanerrorwhenforwardingaresponse,it
dropstheresponse.TheproxySHOULDNOTcancelanyoutstanding
clienttransactionsassociatedwiththisresponsecontextduetothis
notification.
Ifaproxycancelsitsoutstandingclienttransactions,asingle
maliciousormisbehavingclientcancausealltransactionstofail
throughitsViaheaderfield.
16.10CANCELProcessing
AstatefulproxyMAYgenerateaCANCELtoanyotherrequestithas
generatedatanytime(subjecttoreceivingaprovisionalresponseto
thatrequestasdescribedinsection9.1).AproxyMUSTcancelany
pendingclienttransactionsassociatedwitharesponsecontextwhen
itreceivesamatchingCANCELrequest.
AstatefulproxyMAYgenerateCANCELrequestsforpendingINVITE
clienttransactionsbasedontheperiodspecifiedintheINVITE's
Expiresheaderfieldelapsing.However,thisisgenerally
unnecessarysincetheendpointsinvolvedwilltakecareofsignaling
theendofthetransaction.
WhileaCANCELrequestishandledinastatefulproxybyitsown
servertransaction,anewresponsecontextisnotcreatedforit.
Instead,theproxylayersearchesitsexistingresponsecontextsfor
theservertransactionhandlingtherequestassociatedwiththis
CANCEL.Ifamatchingresponsecontextisfound,theelementMUST
immediatelyreturna200(OK)responsetotheCANCELrequest.In
thiscase,theelementisactingasauseragentserverasdefinedin
Section8.2.Furthermore,theelementMUSTgenerateCANCELrequests
forallpendingclienttransactionsinthecontextasdescribedin
Section16.7step10.
Ifaresponsecontextisnotfound,theelementdoesnothaveany
knowledgeoftherequesttoapplytheCANCELto.ItMUSTstatelessly
forwardtheCANCELrequest(itmayhavestatelesslyforwardedthe
associatedrequestpreviously).
Rosenberg,et.al.StandardsTrack[Page115]
RFC3261SIP:SessionInitiationProtocolJune2002
16.11StatelessProxy
Whenactingstatelessly,aproxyisasimplemessageforwarder.Much
oftheprocessingperformedwhenactingstatelesslyisthesameas
whenbehavingstatefully.Thedifferencesaredetailedhere.
Astatelessproxydoesnothaveanynotionofatransaction,orof
theresponsecontextusedtodescribestatefulproxybehavior.
Instead,thestatelessproxytakesmessages,bothrequestsand
responses,directlyfromthetransportlayer(Seesection18).Asa
result,statelessproxiesdonotretransmitmessagesontheirown.
Theydo,however,forwardallretransmissionstheyreceive(theydo
nothavetheabilitytodistinguisharetransmissionfromthe
originalmessage).Furthermore,whenhandlingarequeststatelessly,
anelementMUSTNOTgenerateitsown100(Trying)oranyother
provisionalresponse.
AstatelessproxyMUSTvalidatearequestasdescribedinSection
16.3
AstatelessproxyMUSTfollowtherequestprocessingstepsdescribed
inSections16.4through16.5withthefollowingexception:
oAstatelessproxyMUSTchooseoneandonlyonetargetfromthe
targetset.ThischoiceMUSTonlyrelyonfieldsinthe
messageandtime-invariantpropertiesoftheserver.In
particular,aretransmittedrequestMUSTbeforwardedtothe
samedestinationeachtimeitisprocessed.Furthermore,
CANCELandnon-RoutedACKrequestsMUSTgeneratethesame
choiceastheirassociatedINVITE.
AstatelessproxyMUSTfollowtherequestprocessingstepsdescribed
inSection16.6withthefollowingexceptions:
oTherequirementforuniquebranchIDsacrossspaceandtime
appliestostatelessproxiesaswell.However,astateless
proxycannotsimplyusearandomnumbergeneratortocompute
thefirstcomponentofthebranchID,asdescribedinSection
16.6bullet8.Thisisbecauseretransmissionsofarequest
needtohavethesamevalue,andastatelessproxycannottell
aretransmissionfromtheoriginalrequest.Therefore,the
componentofthebranchparameterthatmakesituniqueMUSTbe
thesameeachtimearetransmittedrequestisforwarded.Thus
forastatelessproxy,thebranchparameterMUSTbecomputedas
acombinatoricfunctionofmessageparameterswhichare
invariantonretransmission.
Rosenberg,et.al.StandardsTrack[Page116]
RFC3261SIP:SessionInitiationProtocolJune2002
ThestatelessproxyMAYuseanytechniqueitlikestoguarantee
uniquenessofitsbranchIDsacrosstransactions.However,the
followingprocedureisRECOMMENDED.Theproxyexaminesthe
branchIDinthetopmostViaheaderfieldofthereceived
request.Ifitbeginswiththemagiccookie,thefirst
componentofthebranchIDoftheoutgoingrequestiscomputed
asahashofthereceivedbranchID.Otherwise,thefirst
componentofthebranchIDiscomputedasahashofthetopmost
Via,thetagintheToheaderfield,thetagintheFromheader
field,theCall-IDheaderfield,theCSeqnumber(butnot
method),andtheRequest-URIfromthereceivedrequest.Oneof
thesefieldswillalwaysvaryacrosstwodifferent
transactions.
oAllothermessagetransformationsspecifiedinSection16.6
MUSTresultinthesametransformationofaretransmitted
request.Inparticular,iftheproxyinsertsaRecord-Route
valueorpushesURIsintotheRouteheaderfield,itMUSTplace
thesamevaluesinretransmissionsoftherequest.Asforthe
Viabranchparameter,thisimpliesthatthetransformations
MUSTbebasedontime-invariantconfigurationor
retransmission-invariantpropertiesoftherequest.
oAstatelessproxydetermineswheretoforwardtherequestas
describedforstatefulproxiesinSection16.6Item10.The
requestissentdirectlytothetransportlayerinsteadof
throughaclienttransaction.
Sinceastatelessproxymustforwardretransmittedrequeststo
thesamedestinationandaddidenticalbranchparametersto
eachofthem,itcanonlyuseinformationfromthemessage
itselfandtime-invariantconfigurationdataforthose
calculations.Iftheconfigurationstateisnottime-invariant
(forexample,ifaroutingtableisupdated)anyrequeststhat
couldbeaffectedbythechangemaynotbeforwarded
statelesslyduringanintervalequaltothetransactiontimeout
windowbeforeorafterthechange.Themethodofprocessing
theaffectedrequestsinthatintervalisanimplementation
decision.Acommonsolutionistoforwardthemtransaction
statefully.
StatelessproxiesMUSTNOTperformspecialprocessingforCANCEL
requests.Theyareprocessedbytheaboverulesasanyother
requests.Inparticular,astatelessproxyappliesthesameRoute
headerfieldprocessingtoCANCELrequeststhatitappliestoany
otherrequest.
Rosenberg,et.al.StandardsTrack[Page117]
RFC3261SIP:SessionInitiationProtocolJune2002
ResponseprocessingasdescribedinSection16.7doesnotapplytoa
proxybehavingstatelessly.Whenaresponsearrivesatastateless
proxy,theproxyMUSTinspectthesent-byvalueinthefirst
(topmost)Viaheaderfieldvalue.Ifthataddressmatchestheproxy,
(itequalsavaluethisproxyhasinsertedintopreviousrequests)
theproxyMUSTremovethatheaderfieldvaluefromtheresponseand
forwardtheresulttothelocationindicatedinthenextViaheader
fieldvalue.TheproxyMUSTNOTaddto,modify,orremovethe
messagebody.Unlessspecifiedotherwise,theproxyMUSTNOTremove
anyotherheaderfieldvalues.Iftheaddressdoesnotmatchthe
proxy,themessageMUSTbesilentlydiscarded.
16.12SummaryofProxyRouteProcessing
Intheabsenceoflocalpolicytothecontrary,theprocessinga
proxyperformsonarequestcontainingaRouteheaderfieldcanbe
summarizedinthefollowingsteps.
1.TheproxywillinspecttheRequest-URI.Ifitindicatesa
resourceownedbythisproxy,theproxywillreplaceitwith
theresultsofrunningalocationservice.Otherwise,the
proxywillnotchangetheRequest-URI.
2.TheproxywillinspecttheURIinthetopmostRouteheader
fieldvalue.Ifitindicatesthisproxy,theproxyremovesit
fromtheRouteheaderfield(thisroutenodehasbeen
reached).
3.Theproxywillforwardtherequesttotheresourceindicated
bytheURIinthetopmostRouteheaderfieldvalueorinthe
Request-URIifnoRouteheaderfieldispresent.Theproxy
determinestheaddress,portandtransporttousewhen
forwardingtherequestbyapplyingtheproceduresin[4]to
thatURI.
Ifnostrict-routingelementsareencounteredonthepathofthe
request,theRequest-URIwillalwaysindicatethetargetofthe
request.
16.12.1Examples
16.12.1.1BasicSIPTrapezoid
ThisscenarioisthebasicSIPtrapezoid,U1->P1->P2->U2,with
bothproxiesrecord-routing.Hereistheflow.
Rosenberg,et.al.StandardsTrack[Page118]
RFC3261SIP:SessionInitiationProtocolJune2002
U1sends:
INVITEsip:[email protected]/2.0
Contact:sip:[email protected]
toP1.P1isanoutboundproxy.P1isnotresponsiblefor
domain.com,soitlooksitupinDNSandsendsitthere.Italso
addsaRecord-Routeheaderfieldvalue:
INVITEsip:[email protected]/2.0
Contact:sip:[email protected]
Record-Route:
P2getsthis.Itisresponsiblefordomain.comsoitrunsalocation
serviceandrewritestheRequest-URI.ItalsoaddsaRecord-Route
headerfieldvalue.ThereisnoRouteheaderfield,soitresolves
thenewRequest-URItodeterminewheretosendtherequest:
INVITEsip:[email protected]/2.0
Contact:sip:[email protected]
Record-Route:
Record-Route:
Thecalleeatu2.domain.comgetsthisandrespondswitha200OK:
SIP/2.0200OK
Contact:sip:[email protected]
Record-Route:
Record-Route:
Thecalleeatu2alsosetsitsdialogstate'sremotetargetURIto
sip:[email protected]:
(,)
ThisisforwardedbyP2toP1toU1asnormal.Now,U1setsits
dialogstate'sremotetargetURItosip:[email protected]
routesetto:
(,)
Sincealltheroutesetelementscontainthelrparameter,U1
constructsthefollowingBYErequest:
BYEsip:[email protected]/2.0
Route:,
Rosenberg,et.al.StandardsTrack[Page119]
RFC3261SIP:SessionInitiationProtocolJune2002
Asanyotherelement(includingproxies)woulddo,itresolvesthe
URIinthetopmostRouteheaderfieldvalueusingDNStodetermine
wheretosendtherequest.ThisgoestoP1.P1noticesthatitis
notresponsiblefortheresourceindicatedintheRequest-URIsoit
doesn'tchangeit.Itdoesseethatitisthefirstvalueinthe
Routeheaderfield,soitremovesthatvalue,andforwardsthe
requesttoP2:
BYEsip:[email protected]/2.0
Route:
P2alsonoticesitisnotresponsiblefortheresourceindicatedby
theRequest-URI(itisresponsiblefordomain.com,not
u2.domain.com),soitdoesn'tchangeit.Itdoesseeitselfinthe
firstRouteheaderfieldvalue,soitremovesitandforwardsthe
followingtou2.domain.combasedonaDNSlookupagainstthe
Request-URI:
BYEsip:[email protected]/2.0
16.12.1.2TraversingaStrict-RoutingProxy
Inthisscenario,adialogisestablishedacrossfourproxies,each
ofwhichaddsRecord-Routeheaderfieldvalues.Thethirdproxy
implementsthestrict-routingproceduresspecifiedinRFC2543and
manyworksinprogress.
U1->P1->P2->P3->P4->U2
TheINVITEarrivingatU2contains:
INVITEsip:[email protected]/2.0
Contact:sip:[email protected]
Record-Route:
Record-Route:
Record-Route:
Record-Route:
WhichU2respondstowitha200OK.Later,U2sendsthefollowing
BYErequesttoP4basedonthefirstRouteheaderfieldvalue.
BYEsip:[email protected]/2.0
Route:
Route:
Route:
Route:
Rosenberg,et.al.StandardsTrack[Page120]
RFC3261SIP:SessionInitiationProtocolJune2002
P4isnotresponsiblefortheresourceindicatedintheRequest-URI
soitwillleaveitalone.Itnoticesthatitistheelementinthe
firstRouteheaderfieldvaluesoitremovesit.Itthenpreparesto
sendtherequestbasedonthenowfirstRouteheaderfieldvalueof
sip:p3.middle.com,butitnoticesthatthisURIdoesnotcontainthe
lrparameter,sobeforesending,itreformatstherequesttobe:
BYEsip:p3.middle.comSIP/2.0
Route:
Route:
Route:
P3isastrictrouter,soitforwardsthefollowingtoP2:
BYEsip:p2.example.com;lrSIP/2.0
Route:
Route:
P2seestherequest-URIisavalueitplacedintoaRecord-Route
headerfield,sobeforefurtherprocessing,itrewritestherequest
tobe:
BYEsip:[email protected]/2.0
Route:
P2isnotresponsibleforu1.example.com,soitsendstherequestto
P1basedontheresolutionoftheRouteheaderfieldvalue.
P1noticesitselfinthetopmostRouteheaderfieldvalue,soit
removesit,resultingin:
BYEsip:[email protected]/2.0
SinceP1isnotresponsibleforu1.example.comandthereisnoRoute
headerfield,P1willforwardtherequesttou1.example.combasedon
theRequest-URI.
16.12.1.3RewritingRecord-RouteHeaderFieldValues
Inthisscenario,U1andU2areindifferentprivatenamespacesand
theyenteradialogthroughaproxyP1,whichactsasagateway
betweenthenamespaces.
U1->P1->U2
Rosenberg,et.al.StandardsTrack[Page121]
RFC3261SIP:SessionInitiationProtocolJune2002
U1sends:
INVITEsip:[email protected]/2.0
Contact:
P1usesitslocationserviceandsendsthefollowingtoU2:
INVITEsip:[email protected]/2.0
Contact:
Record-Route:
U2sendsthis200(OK)backtoP1:
SIP/2.0200OK
Contact:
Record-Route:
P1rewritesitsRecord-Routeheaderparametertoprovideavaluethat
U1willfinduseful,andsendsthefollowingtoU1:
SIP/2.0200OK
Contact:
Record-Route:
Later,U1sendsthefollowingBYErequesttoP1:
BYEsip:[email protected]/2.0
Route:
whichP1forwardstoU2as:
BYEsip:[email protected]/2.0
17Transactions
SIPisatransactionalprotocol:interactionsbetweencomponentstake
placeinaseriesofindependentmessageexchanges.Specifically,a
SIPtransactionconsistsofasinglerequestandanyresponsesto
thatrequest,whichincludezeroormoreprovisionalresponsesand
oneormorefinalresponses.Inthecaseofatransactionwherethe
requestwasanINVITE(knownasanINVITEtransaction),the
transactionalsoincludestheACKonlyifthefinalresponsewasnot
a2xxresponse.Iftheresponsewasa2xx,theACKisnotconsidered
partofthetransaction.
Thereasonforthisseparationisrootedintheimportanceof
deliveringall200(OK)responsestoanINVITEtotheUAC.To
deliverthemalltotheUAC,theUASalonetakesresponsibility
Rosenberg,et.al.StandardsTrack[Page122]
RFC3261SIP:SessionInitiationProtocolJune2002
forretransmittingthem(seeSection13.3.1.4),andtheUACalone
takesresponsibilityforacknowledgingthemwithACK(seeSection
13.2.2.4).SincethisACKisretransmittedonlybytheUAC,itis
effectivelyconsidereditsowntransaction.
Transactionshaveaclientsideandaserverside.Theclientside
isknownasaclienttransactionandtheserversideasaserver
transaction.Theclienttransactionsendstherequest,andthe
servertransactionsendstheresponse.Theclientandserver
transactionsarelogicalfunctionsthatareembeddedinanynumberof
elements.Specifically,theyexistwithinuseragentsandstateful
proxyservers.ConsidertheexampleinSection4.Inthisexample,
theUACexecutestheclienttransaction,anditsoutboundproxy
executestheservertransaction.Theoutboundproxyalsoexecutesa
clienttransaction,whichsendstherequesttoaservertransaction
intheinboundproxy.Thatproxyalsoexecutesaclienttransaction,
whichinturnsendstherequesttoaservertransactionintheUAS.
ThisisshowninFigure4.
+---------++---------++---------++---------+
|+-+|Request|+-++-+|Request|+-++-+|Request|+-+|
||C||------->||S||C||------->||S||C||------->||S||
||l||||e||l||||e||l||||e||
||i||||r||i||||r||i||||r||
||e||||v||e||||v||e||||v||
||n||||e||n||||e||n||||e||
||t||||r||t||||r||t||||r||
||||||||||||||||||||
||T||||T||T||||T||T||||T||
||r||||r||r||||r||r||||r||
||a||||a||a||||a||a||||a||
||n||||n||n||||n||n||||n||
||s||Response||s||s||Response||s||s||Response||s||
|+-+|||-------------->|
+-----------+2xx|
||2xxtoTU|
||1xx|
300-699+---------------+|1xxtoTU|
ACKsent|||
resp.toTU|1xxV|
|1xxtoTU-----------+|
|+---------|||
|||Proceeding|-------------->|
|+-------->||2xx|
|+-----------+2xxtoTU|
|300-699||
|ACKsent,||
|resp.toTU||
|||NOTE:
|300-699V|
|ACKsent+-----------+TransportErr.|transitions
|+---------||InformTU|labeledwith
|||Completed|-------------->|theevent
|+-------->|||overtheaction
|+-----------+|totake
|^||
|||TimerDfires|
+--------------+|-|
||
V|
+-----------+|
|||
|Terminated|
From:Alice;tag=88sja8x
Max-Forwards:70
Call-ID:987asjd97y7atg
CSeq:986759INVITE
TheACKrequestforanon-2xxfinalresponsetothisrequestwould
looklikethis:
ACKsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKkjshdyff
To:Bob;tag=99sa0xk
From:Alice;tag=88sja8x
Max-Forwards:70
Call-ID:987asjd97y7atg
CSeq:986759ACK
17.1.2Non-INVITEClientTransaction
17.1.2.1Overviewofthenon-INVITETransaction
Non-INVITEtransactionsdonotmakeuseofACK.Theyaresimple
request-responseinteractions.Forunreliabletransports,requests
areretransmittedatanintervalwhichstartsatT1anddoublesuntil
ithitsT2.Ifaprovisionalresponseisreceived,retransmissions
continueforunreliabletransports,butatanintervalofT2.The
servertransactionretransmitsthelastresponseitsent,whichcan
beaprovisionalorfinalresponse,onlywhenaretransmissionofthe
requestisreceived.Thisiswhyrequestretransmissionsneedto
continueevenafteraprovisionalresponse;theyaretoensure
reliabledeliveryofthefinalresponse.
Rosenberg,et.al.StandardsTrack[Page130]
RFC3261SIP:SessionInitiationProtocolJune2002
UnlikeanINVITEtransaction,anon-INVITEtransactionhasnospecial
handlingforthe2xxresponse.Theresultisthatonlyasingle2xx
responsetoanon-INVITEiseverdeliveredtoaUAC.
17.1.2.2FormalDescription
Thestatemachineforthenon-INVITEclienttransactionisshownin
Figure6.ItisverysimilartothestatemachineforINVITE.
The"Trying"stateisenteredwhentheTUinitiatesanewclient
transactionwitharequest.Whenenteringthisstate,theclient
transactionSHOULDsettimerFtofirein64*T1seconds.Therequest
MUSTbepassedtothetransportlayerfortransmission.Ifan
unreliabletransportisinuse,theclienttransactionMUSTsettimer
EtofireinT1seconds.IftimerEfireswhilestillinthisstate,
thetimerisreset,butthistimewithavalueofMIN(2*T1,T2).
Whenthetimerfiresagain,itisresettoaMIN(4*T1,T2).This
processcontinuessothatretransmissionsoccurwithanexponentially
increasingintervalthatcapsatT2.ThedefaultvalueofT2is4s,
anditrepresentstheamountoftimeanon-INVITEservertransaction
willtaketorespondtoarequest,ifitdoesnotrespond
immediately.ForthedefaultvaluesofT1andT2,thisresultsin
intervalsof500ms,1s,2s,4s,4s,4s,etc.
IfTimerFfireswhiletheclienttransactionisstillinthe
"Trying"state,theclienttransactionSHOULDinformtheTUaboutthe
timeout,andthenitSHOULDenterthe"Terminated"state.Ifa
provisionalresponseisreceivedwhileinthe"Trying"state,the
responseMUSTbepassedtotheTU,andthentheclienttransaction
SHOULDmovetothe"Proceeding"state.Ifafinalresponse(status
codes200-699)isreceivedwhileinthe"Trying"state,theresponse
MUSTbepassedtotheTU,andtheclienttransactionMUSTtransition
tothe"Completed"state.
IfTimerEfireswhileinthe"Proceeding"state,therequestMUSTbe
passedtothetransportlayerforretransmission,andTimerEMUSTbe
resetwithavalueofT2seconds.IftimerFfireswhileinthe
"Proceeding"state,theTUMUSTbeinformedofatimeout,andthe
clienttransactionMUSTtransitiontotheterminatedstate.Ifa
finalresponse(statuscodes200-699)isreceivedwhileinthe
"Proceeding"state,theresponseMUSTbepassedtotheTU,andthe
clienttransactionMUSTtransitiontothe"Completed"state.
Oncetheclienttransactionentersthe"Completed"state,itMUSTset
TimerKtofireinT4secondsforunreliabletransports,andzero
secondsforreliabletransports.The"Completed"stateexiststo
bufferanyadditionalresponseretransmissionsthatmaybereceived
(whichiswhytheclienttransactionremainsthereonlyfor
Rosenberg,et.al.StandardsTrack[Page131]
RFC3261SIP:SessionInitiationProtocolJune2002
unreliabletransports).T4representstheamountoftimethenetwork
willtaketoclearmessagesbetweenclientandservertransactions.
ThedefaultvalueofT4is5s.Aresponseisaretransmissionwhen
itmatchesthesametransaction,usingtherulesspecifiedinSection
17.1.3.IfTimerKfireswhileinthisstate,theclienttransaction
MUSTtransitiontothe"Terminated"state.
Oncethetransactionisintheterminatedstate,itMUSTbedestroyed
immediately.
17.1.3MatchingResponsestoClientTransactions
Whenthetransportlayerintheclientreceivesaresponse,ithasto
determinewhichclienttransactionwillhandletheresponse,sothat
theprocessingofSections17.1.1and17.1.2cantakeplace.The
branchparameterinthetopViaheaderfieldisusedforthis
purpose.Aresponsematchesaclienttransactionundertwo
conditions:
1.Iftheresponsehasthesamevalueofthebranchparameterin
thetopViaheaderfieldasthebranchparameterinthetop
Viaheaderfieldoftherequestthatcreatedthetransaction.
2.IfthemethodparameterintheCSeqheaderfieldmatchesthe
methodoftherequestthatcreatedthetransaction.The
methodisneededsinceaCANCELrequestconstitutesa
differenttransaction,butsharesthesamevalueofthebranch
parameter.
Ifarequestissentviamulticast,itispossiblethatitwill
generatemultipleresponsesfromdifferentservers.Theseresponses
willallhavethesamebranchparameterinthetopmostVia,butvary
intheTotag.Thefirstresponsereceived,basedontherules
above,willbeused,andotherswillbeviewedasretransmissions.
Thatisnotanerror;multicastSIPprovidesonlyarudimentary
"single-hop-discovery-like"servicethatislimitedtoprocessinga
singleresponse.SeeSection18.1.1fordetails.
Rosenberg,et.al.StandardsTrack[Page132]
RFC3261SIP:SessionInitiationProtocolJune2002
17.1.4HandlingTransportErrors
|RequestfromTU
|sendrequest
TimerEV
sendrequest+-----------+
+---------||-------------------+
||Trying|TimerF|
+-------->||orTransportErr.|
+-----------+informTU|
200-699|||
resp.toTU||1xx|
+---------------+|resp.toTU|
|||
|TimerEVTimerF|
|sendreq+-----------+orTransportErr.|
|+---------||informTU|
|||Proceeding|------------------>|
|+-------->||-----+|
|+-----------+|1xx|
||^|resptoTU|
|200-699|+--------+|
|resp.toTU||
|||
|V|
|+-----------+|
||||
||Completed||
||||
|+-----------+|
|^||
|||TimerK|
+--------------+|-|
||
V|
NOTE:+-----------+|
|||
transitions|Terminated|||+
+-----------+|
300-699fromTU||2xxfromTU|
sendresponse||sendresponse|
|+------------------>+
||
INVITEVTimerGfires|
sendresponse+-----------+sendresponse|
+--------||--------+|
||Completed|||
+------->||+
|TimerHfires|
VorTransportErr.|
+-----------+InformTU|
|||
|Confirmed||
|||
+-----------+|
||
|TimerIfires|
|-|
||
V|
+-----------+|
|||
|Terminated|||||
+|Terminated|
||
+-----------+
Figure8:non-INVITEservertransaction
Forallotherrequestmethods,arequestismatchedtoatransaction
iftheRequest-URI,Totag,Fromtag,Call-ID,CSeq(includingthe
method),andtopViaheaderfieldmatchthoseoftherequestthat
createdthetransaction.Matchingisdonebasedonthematching
Rosenberg,et.al.StandardsTrack[Page140]
RFC3261SIP:SessionInitiationProtocolJune2002
rulesdefinedforeachofthoseheaderfields.Whenanon-INVITE
requestmatchesanexistingtransaction,itisaretransmissionof
therequestthatcreatedthattransaction.
BecausethematchingrulesincludetheRequest-URI,theservercannot
matcharesponsetoatransaction.WhentheTUpassesaresponseto
theservertransaction,itmustpassittothespecificserver
transactionforwhichtheresponseistargeted.
17.2.4HandlingTransportErrors
Whentheservertransactionsendsaresponsetothetransportlayer
tobesent,thefollowingproceduresarefollowedifthetransport
layerindicatesafailure.
First,theproceduresin[4]arefollowed,whichattempttodeliver
theresponsetoabackup.Ifthoseshouldallfail,basedonthe
definitionoffailurein[4],theservertransactionSHOULDinform
theTUthatafailurehasoccurred,andSHOULDtransitiontothe
terminatedstate.
18Transport
Thetransportlayerisresponsiblefortheactualtransmissionof
requestsandresponsesovernetworktransports.Thisincludes
determinationoftheconnectiontouseforarequestorresponsein
thecaseofconnection-orientedtransports.
Thetransportlayerisresponsibleformanagingpersistent
connectionsfortransportprotocolslikeTCPandSCTP,orTLSover
those,includingonesopenedtothetransportlayer.Thisincludes
connectionsopenedbytheclientorservertransports,sothat
connectionsaresharedbetweenclientandservertransportfunctions.
Theseconnectionsareindexedbythetupleformedfromtheaddress,
port,andtransportprotocolatthefarendoftheconnection.When
aconnectionisopenedbythetransportlayer,thisindexissetto
thedestinationIP,portandtransport.Whentheconnectionis
acceptedbythetransportlayer,thisindexissettothesourceIP
address,portnumber,andtransport.Notethat,becausethesource
portisoftenephemeral,butitcannotbeknownwhetheritis
ephemeralorselectedthroughproceduresin[4],connectionsaccepted
bythetransportlayerwillfrequentlynotbereused.Theresultis
thattwoproxiesina"peering"relationshipusingaconnection-
orientedtransportfrequentlywillhavetwoconnectionsinuse,one
fortransactionsinitiatedineachdirection.
Rosenberg,et.al.StandardsTrack[Page141]
RFC3261SIP:SessionInitiationProtocolJune2002
ItisRECOMMENDEDthatconnectionsbekeptopenforsome
implementation-defineddurationafterthelastmessagewassentor
receivedoverthatconnection.ThisdurationSHOULDatleastequal
thelongestamountoftimetheelementwouldneedinordertobringa
transactionfrominstantiationtotheterminatedstate.Thisisto
makeitlikelythattransactionsarecompletedoverthesame
connectiononwhichtheyareinitiated(forexample,request,
response,andinthecaseofINVITE,ACKfornon-2xxresponses).
Thisusuallymeansatleast64*T1(seeSection17.1.1.1fora
definitionofT1).However,itcouldbelargerinanelementthat
hasaTUusingalargevaluefortimerC(bullet11ofSection16.6),
forexample.
AllSIPelementsMUSTimplementUDPandTCP.SIPelementsMAY
implementotherprotocols.
MakingTCPmandatoryfortheUAisasubstantialchangefromRFC
2543.Ithasarisenoutoftheneedtohandlelargermessages,
whichMUSTuseTCP,asdiscussedbelow.Thus,evenifanelement
neversendslargemessages,itmayreceiveoneandneedstobe
abletohandlethem.
18.1Clients
18.1.1SendingRequests
Theclientsideofthetransportlayerisresponsibleforsendingthe
requestandreceivingresponses.Theuserofthetransportlayer
passestheclienttransporttherequest,anIPaddress,port,
transport,andpossiblyTTLformulticastdestinations.
Ifarequestiswithin200bytesofthepathMTU,orifitislarger
than1300bytesandthepathMTUisunknown,therequestMUSTbesent
usinganRFC2914[43]congestioncontrolledtransportprotocol,such
asTCP.Ifthiscausesachangeinthetransportprotocolfromthe
oneindicatedinthetopVia,thevalueinthetopViaMUSTbe
changed.ThispreventsfragmentationofmessagesoverUDPand
providescongestioncontrolforlargermessages.However,
implementationsMUSTbeabletohandlemessagesuptothemaximum
datagrampacketsize.ForUDP,thissizeis65,535bytes,including
IPandUDPheaders.
The200byte"buffer"betweenthemessagesizeandtheMTU
accommodatesthefactthattheresponseinSIPcanbelargerthan
therequest.ThishappensduetotheadditionofRecord-Route
headerfieldvaluestotheresponsestoINVITE,forexample.With
theextrabuffer,theresponsecanbeabout170byteslargerthan
therequest,andstillnotbefragmentedonIPv4(about30bytes
Rosenberg,et.al.StandardsTrack[Page142]
RFC3261SIP:SessionInitiationProtocolJune2002
isconsumedbyIP/UDP,assumingnoIPSec).1300ischosenwhen
pathMTUisnotknown,basedontheassumptionofa1500byte
EthernetMTU.
IfanelementsendsarequestoverTCPbecauseofthesemessagesize
constraints,andthatrequestwouldhaveotherwisebeensentover
UDP,iftheattempttoestablishtheconnectiongenerateseitheran
ICMPProtocolNotSupported,orresultsinaTCPreset,theelement
SHOULDretrytherequest,usingUDP.Thisisonlytoprovide
backwardscompatibilitywithRFC2543compliantimplementationsthat
donotsupportTCP.Itisanticipatedthatthisbehaviorwillbe
deprecatedinafuturerevisionofthisspecification.
AclientthatsendsarequesttoamulticastaddressMUSTaddthe
"maddr"parametertoitsViaheaderfieldvaluecontainingthe
destinationmulticastaddress,andforIPv4,SHOULDaddthe"ttl"
parameterwithavalueof1.UsageofIPv6multicastisnotdefined
inthisspecification,andwillbeasubjectoffuture
standardizationwhentheneedarises.
TheserulesresultinapurposefullimitationofmulticastinSIP.
Itsprimaryfunctionistoprovidea"single-hop-discovery-like"
service,deliveringarequesttoagroupofhomogeneousservers,
whereitisonlyrequiredtoprocesstheresponsefromanyoneof
them.Thisfunctionalityismostusefulforregistrations.Infact,
basedonthetransactionprocessingrulesinSection17.1.3,the
clienttransactionwillacceptthefirstresponse,andviewany
othersasretransmissionsbecausetheyallcontainthesameVia
branchidentifier.
Beforearequestissent,theclienttransportMUSTinsertavalueof
the"sent-by"fieldintotheViaheaderfield.Thisfieldcontains
anIPaddressorhostname,andport.TheusageofanFQDNis
RECOMMENDED.Thisfieldisusedforsendingresponsesundercertain
conditions,describedbelow.Iftheportisabsent,thedefault
valuedependsonthetransport.Itis5060forUDP,TCPandSCTP,
5061forTLS.
Forreliabletransports,theresponseisnormallysentonthe
connectiononwhichtherequestwasreceived.Therefore,theclient
transportMUSTbepreparedtoreceivetheresponseonthesame
connectionusedtosendtherequest.Undererrorconditions,the
servermayattempttoopenanewconnectiontosendtheresponse.To
handlethiscase,thetransportlayerMUSTalsobepreparedto
receiveanincomingconnectiononthesourceIPaddressfromwhich
therequestwassentandportnumberinthe"sent-by"field.Italso
Rosenberg,et.al.StandardsTrack[Page143]
RFC3261SIP:SessionInitiationProtocolJune2002
MUSTbepreparedtoreceiveincomingconnectionsonanyaddressand
portthatwouldbeselectedbyaserverbasedontheprocedures
describedinSection5of[4].
Forunreliableunicasttransports,theclienttransportMUSTbe
preparedtoreceiveresponsesonthesourceIPaddressfromwhichthe
requestissent(asresponsesaresentbacktothesourceaddress)
andtheportnumberinthe"sent-by"field.Furthermore,aswith
reliabletransports,incertaincasestheresponsewillbesent
elsewhere.TheclientMUSTbepreparedtoreceiveresponsesonany
addressandportthatwouldbeselectedbyaserverbasedonthe
proceduresdescribedinSection5of[4].
Formulticast,theclienttransportMUSTbepreparedtoreceive
responsesonthesamemulticastgroupandporttowhichtherequest
issent(thatis,itneedstobeamemberofthemulticastgroupit
senttherequestto.)
IfarequestisdestinedtoanIPaddress,port,andtransportto
whichanexistingconnectionisopen,itisRECOMMENDEDthatthis
connectionbeusedtosendtherequest,butanotherconnectionMAYbe
openedandused.
Ifarequestissentusingmulticast,itissenttothegroup
address,port,andTTLprovidedbythetransportuser.Ifarequest
issentusingunicastunreliabletransports,itissenttotheIP
addressandportprovidedbythetransportuser.
18.1.2ReceivingResponses
Whenaresponseisreceived,theclienttransportexaminesthetop
Viaheaderfieldvalue.Ifthevalueofthe"sent-by"parameterin
thatheaderfieldvaluedoesnotcorrespondtoavaluethatthe
clienttransportisconfiguredtoinsertintorequests,theresponse
MUSTbesilentlydiscarded.
Ifthereareanyclienttransactionsinexistence,theclient
transportusesthematchingproceduresofSection17.1.3toattempt
tomatchtheresponsetoanexistingtransaction.Ifthereisa
match,theresponseMUSTbepassedtothattransaction.Otherwise,
theresponseMUSTbepassedtothecore(whetheritbestateless
proxy,statefulproxy,orUA)forfurtherprocessing.Handlingof
these"stray"responsesisdependentonthecore(aproxywill
forwardthem,whileaUAwilldiscard,forexample).
Rosenberg,et.al.StandardsTrack[Page144]
RFC3261SIP:SessionInitiationProtocolJune2002
18.2Servers
18.2.1ReceivingRequests
AserverSHOULDbepreparedtoreceiverequestsonanyIPaddress,
portandtransportcombinationthatcanbetheresultofaDNSlookup
onaSIPorSIPSURI[4]thatishandedoutforthepurposesof
communicatingwiththatserver.Inthiscontext,"handingout"
includesplacingaURIinaContactheaderfieldinaREGISTER
requestoraredirectresponse,orinaRecord-Routeheaderfieldin
arequestorresponse.AURIcanalsobe"handedout"byplacingit
onawebpageorbusinesscard.ItisalsoRECOMMENDEDthataserver
listenforrequestsonthedefaultSIPports(5060forTCPandUDP,
5061forTLSoverTCP)onallpublicinterfaces.Thetypical
exceptionwouldbeprivatenetworks,orwhenmultipleserver
instancesarerunningonthesamehost.Foranyportandinterface
thataserverlistensonforUDP,itMUSTlistenonthatsameport
andinterfaceforTCP.Thisisbecauseamessagemayneedtobesent
usingTCP,ratherthanUDP,ifitistoolarge.Asaresult,the
converseisnottrue.AserverneednotlistenforUDPona
particularaddressandportjustbecauseitislisteningonthatsame
addressandportforTCP.Theremay,ofcourse,beotherreasonswhy
aserverneedstolistenforUDPonaparticularaddressandport.
Whentheservertransportreceivesarequestoveranytransport,it
MUSTexaminethevalueofthe"sent-by"parameterinthetopVia
headerfieldvalue.Ifthehostportionofthe"sent-by"parameter
containsadomainname,orifitcontainsanIPaddressthatdiffers
fromthepacketsourceaddress,theserverMUSTadda"received"
parametertothatViaheaderfieldvalue.ThisparameterMUST
containthesourceaddressfromwhichthepacketwasreceived.This
istoassisttheservertransportlayerinsendingtheresponse,
sinceitmustbesenttothesourceIPaddressfromwhichtherequest
came.
Considerarequestreceivedbytheservertransportwhichlookslike,
inpart:
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPbobspc.biloxi.com:5060
TherequestisreceivedwithasourceIPaddressof192.0.2.4.
Beforepassingtherequestup,thetransportaddsa"received"
parameter,sothattherequestwouldlooklike,inpart:
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPbobspc.biloxi.com:5060;received=192.0.2.4
Rosenberg,et.al.StandardsTrack[Page145]
RFC3261SIP:SessionInitiationProtocolJune2002
Next,theservertransportattemptstomatchtherequesttoaserver
transaction.Itdoessousingthematchingrulesdescribedin
Section17.2.3.Ifamatchingservertransactionisfound,the
requestispassedtothattransactionforprocessing.Ifnomatchis
found,therequestispassedtothecore,whichmaydecideto
constructanewservertransactionforthatrequest.Notethatwhen
aUAScoresendsa2xxresponsetoINVITE,theservertransactionis
destroyed.ThismeansthatwhentheACKarrives,therewillbeno
matchingservertransaction,andbasedonthisrule,theACKis
passedtotheUAScore,whereitisprocessed.
18.2.2SendingResponses
TheservertransportusesthevalueofthetopViaheaderfieldin
ordertodeterminewheretosendaresponse.ItMUSTfollowthe
followingprocess:
oIfthe"sent-protocol"isareliabletransportprotocolsuchas
TCPorSCTP,orTLSoverthose,theresponseMUSTbesentusing
theexistingconnectiontothesourceoftheoriginalrequest
thatcreatedthetransaction,ifthatconnectionisstillopen.
Thisrequirestheservertransporttomaintainanassociation
betweenservertransactionsandtransportconnections.Ifthat
connectionisnolongeropen,theserverSHOULDopena
connectiontotheIPaddressinthe"received"parameter,if
present,usingtheportinthe"sent-by"value,orthedefault
portforthattransport,ifnoportisspecified.Ifthat
connectionattemptfails,theserverSHOULDusetheprocedures
in[4]forserversinordertodeterminetheIPaddressand
porttoopentheconnectionandsendtheresponseto.
oOtherwise,iftheViaheaderfieldvaluecontainsa"maddr"
parameter,theresponseMUSTbeforwardedtotheaddresslisted
there,usingtheportindicatedin"sent-by",orport5060if
noneispresent.Iftheaddressisamulticastaddress,the
responseSHOULDbesentusingtheTTLindicatedinthe"ttl"
parameter,orwithaTTLof1ifthatparameterisnotpresent.
oOtherwise(forunreliableunicasttransports),ifthetopVia
hasa"received"parameter,theresponseMUSTbesenttothe
addressinthe"received"parameter,usingtheportindicated
inthe"sent-by"value,orusingport5060ifnoneisspecified
explicitly.Ifthisfails,forexample,elicitsanICMP"port
unreachable"response,theproceduresofSection5of[4]
SHOULDbeusedtodeterminewheretosendtheresponse.
Rosenberg,et.al.StandardsTrack[Page146]
RFC3261SIP:SessionInitiationProtocolJune2002
oOtherwise,ifitisnotreceiver-tagged,theresponseMUSTbe
senttotheaddressindicatedbythe"sent-by"value,usingthe
proceduresinSection5of[4].
18.3Framing
Inthecaseofmessage-orientedtransports(suchasUDP),ifthe
messagehasaContent-Lengthheaderfield,themessagebodyis
assumedtocontainthatmanybytes.Ifthereareadditionalbytesin
thetransportpacketbeyondtheendofthebody,theyMUSTbe
discarded.Ifthetransportpacketendsbeforetheendofthe
messagebody,thisisconsideredanerror.Ifthemessageisa
response,itMUSTbediscarded.Ifthemessageisarequest,the
elementSHOULDgeneratea400(BadRequest)response.Ifthemessage
hasnoContent-Lengthheaderfield,themessagebodyisassumedto
endattheendofthetransportpacket.
Inthecaseofstream-orientedtransportssuchasTCP,theContent-
Lengthheaderfieldindicatesthesizeofthebody.TheContent-
LengthheaderfieldMUSTbeusedwithstreamorientedtransports.
18.4ErrorHandling
Errorhandlingisindependentofwhetherthemessagewasarequestor
response.
Ifthetransportuserasksforamessagetobesentoveran
unreliabletransport,andtheresultisanICMPerror,thebehavior
dependsonthetypeofICMPerror.Host,network,portorprotocol
unreachableerrors,orparameterproblemerrorsSHOULDcausethe
transportlayertoinformthetransportuserofafailureinsending.
SourcequenchandTTLexceededICMPerrorsSHOULDbeignored.
Ifthetransportuserasksforarequesttobesentoverareliable
transport,andtheresultisaconnectionfailure,thetransport
layerSHOULDinformthetransportuserofafailureinsending.
19CommonMessageComponents
TherearecertaincomponentsofSIPmessagesthatappearinvarious
placeswithinSIPmessages(andsometimes,outsideofthem)that
meritseparatediscussion.
Rosenberg,et.al.StandardsTrack[Page147]
RFC3261SIP:SessionInitiationProtocolJune2002
19.1SIPandSIPSUniformResourceIndicators
ASIPorSIPSURIidentifiesacommunicationsresource.Likeall
URIs,SIPandSIPSURIsmaybeplacedinwebpages,emailmessages,
orprintedliterature.Theycontainsufficientinformationto
initiateandmaintainacommunicationsessionwiththeresource.
Examplesofcommunicationsresourcesincludethefollowing:
oauserofanonlineservice
oanappearanceonamulti-linephone
oamailboxonamessagingsystem
oaPSTNnumberatagatewayservice
oagroup(suchas"sales"or"helpdesk")inanorganization
ASIPSURIspecifiesthattheresourcebecontactedsecurely.This
means,inparticular,thatTLSistobeusedbetweentheUACandthe
domainthatownstheURI.Fromthere,securecommunicationsareused
toreachtheuser,wherethespecificsecuritymechanismdependson
thepolicyofthedomain.AnyresourcedescribedbyaSIPURIcanbe
"upgraded"toaSIPSURIbyjustchangingthescheme,ifitis
desiredtocommunicatewiththatresourcesecurely.
19.1.1SIPandSIPSURIComponents
The"sip:"and"sips:"schemesfollowtheguidelinesinRFC2396[5].
TheyuseaformsimilartothemailtoURL,allowingthespecification
ofSIPrequest-headerfieldsandtheSIPmessage-body.Thismakesit
possibletospecifythesubject,mediatype,orurgencyofsessions
initiatedbyusingaURIonawebpageorinanemailmessage.The
formalsyntaxforaSIPorSIPSURIispresentedinSection25.Its
generalform,inthecaseofaSIPURI,is:
sip:user:password@host:port;uri-parameters?headers
TheformatforaSIPSURIisthesame,exceptthattheschemeis
"sips"insteadofsip.Thesetokens,andsomeofthetokensintheir
expansions,havethefollowingmeanings:
user:Theidentifierofaparticularresourceatthehostbeing
addressed.Theterm"host"inthiscontextfrequentlyrefers
toadomain.The"userinfo"ofaURIconsistsofthisuser
field,thepasswordfield,[email protected]
userinfopartofaURIisoptionalandMAYbeabsentwhenthe
Rosenberg,et.al.StandardsTrack[Page148]
RFC3261SIP:SessionInitiationProtocolJune2002
destinationhostdoesnothaveanotionofusersorwhenthe
hostitselfistheresourcebeingidentified.Ifthe@signis
presentinaSIPorSIPSURI,theuserfieldMUSTNOTbeempty.
Ifthehostbeingaddressedcanprocesstelephonenumbers,for
instance,anInternettelephonygateway,atelephone-
subscriberfielddefinedinRFC2806[9]MAYbeusedto
populatetheuserfield.Therearespecialescapingrulesfor
encodingtelephone-subscriberfieldsinSIPandSIPSURIs
describedinSection19.1.2.
password:Apasswordassociatedwiththeuser.WhiletheSIPand
SIPSURIsyntaxallowsthisfieldtobepresent,itsuseisNOT
RECOMMENDED,becausethepassingofauthenticationinformation
incleartext(suchasURIs)hasproventobeasecurityrisk
inalmosteverycasewhereithasbeenused.Forinstance,
transportingaPINnumberinthisfieldexposesthePIN.
Notethatthepasswordfieldisjustanextensionoftheuser
portion.Implementationsnotwishingtogivespecial
significancetothepasswordportionofthefieldMAYsimply
treat"user:password"asasinglestring.
host:ThehostprovidingtheSIPresource.Thehostpartcontains
eitherafully-qualifieddomainnameornumericIPv4orIPv6
address.Usingthefully-qualifieddomainnameformis
RECOMMENDEDwheneverpossible.
port:Theportnumberwheretherequestistobesent.
URIparameters:Parametersaffectingarequestconstructedfrom
theURI.
URIparametersareaddedafterthehostportcomponentandare
separatedbysemi-colons.
URIparameterstaketheform:
parameter-name"="parameter-value
EventhoughanarbitrarynumberofURIparametersmaybe
includedinaURI,anygivenparameter-nameMUSTNOTappear
morethanonce.
Thisextensiblemechanismincludesthetransport,maddr,ttl,
user,methodandlrparameters.
Rosenberg,et.al.StandardsTrack[Page149]
RFC3261SIP:SessionInitiationProtocolJune2002
Thetransportparameterdeterminesthetransportmechanismto
beusedforsendingSIPmessages,asspecifiedin[4].SIPcan
useanynetworktransportprotocol.Parameternamesare
definedforUDP(RFC768[14]),TCP(RFC761[15]),andSCTP
(RFC2960[16]).ForaSIPSURI,thetransportparameterMUST
indicateareliabletransport.
Themaddrparameterindicatestheserveraddresstobe
contactedforthisuser,overridinganyaddressderivedfrom
thehostfield.Whenanmaddrparameterispresent,theport
andtransportcomponentsoftheURIapplytotheaddress
indicatedinthemaddrparametervalue.[4]describesthe
properinterpretationofthetransport,maddr,andhostportin
ordertoobtainthedestinationaddress,port,andtransport
forsendingarequest.
Themaddrfieldhasbeenusedasasimpleformofloosesource
routing.ItallowsaURItospecifyaproxythatmustbe
traverseden-routetothedestination.Continuingtousethe
maddrparameterthiswayisstronglydiscouraged(the
mechanismsthatenableitaredeprecated).Implementations
shouldinsteadusetheRoutemechanismdescribedinthis
document,establishingapre-existingroutesetifnecessary
(seeSection8.1.1.1).ThisprovidesafullURItodescribe
thenodetobetraversed.
Thettlparameterdeterminesthetime-to-livevalueoftheUDP
multicastpacketandMUSTonlybeusedifmaddrisamulticast
addressandthetransportprotocolisUDP.Forexample,to
[email protected]
239.255.255.1withattlof15,thefollowingURIwouldbe
used:
sip:[email protected];maddr=239.255.255.1;ttl=15
Thesetofvalidtelephone-subscriberstringsisasubsetof
validuserstrings.TheuserURIparameterexiststo
distinguishtelephonenumbersfromusernamesthathappento
lookliketelephonenumbers.Iftheuserstringcontainsa
telephonenumberformattedasatelephone-subscriber,theuser
parametervalue"phone"SHOULDbepresent.Evenwithoutthis
parameter,recipientsofSIPandSIPSURIsMAYinterpretthe
pre-@partasatelephonenumberiflocalrestrictionsonthe
namespaceforusernameallowit.
ThemethodoftheSIPrequestconstructedfromtheURIcanbe
specifiedwiththemethodparameter.
Rosenberg,et.al.StandardsTrack[Page150]
RFC3261SIP:SessionInitiationProtocolJune2002
Thelrparameter,whenpresent,indicatesthattheelement
responsibleforthisresourceimplementstheroutingmechanisms
specifiedinthisdocument.Thisparameterwillbeusedinthe
URIsproxiesplaceintoRecord-Routeheaderfieldvalues,and
mayappearintheURIsinapre-existingrouteset.
Thisparameterisusedtoachievebackwardscompatibilitywith
systemsimplementingthestrict-routingmechanismsofRFC2543
andtherfc2543bisdraftsuptobis-05.Anelementpreparing
tosendarequestbasedonaURInotcontainingthisparameter
canassumethereceivingelementimplementsstrict-routingand
reformatthemessagetopreservetheinformationinthe
Request-URI.
Sincetheuri-parametermechanismisextensible,SIPelements
MUSTsilentlyignoreanyuri-parametersthattheydonot
understand.
Headers:Headerfieldstobeincludedinarequestconstructed
fromtheURI.
HeadersfieldsintheSIPrequestcanbespecifiedwiththe"?"
mechanismwithinaURI.Theheadernamesandvaluesare
encodedinampersandseparatedhname=hvaluepairs.The
specialhname"body"indicatesthattheassociatedhvalueis
themessage-bodyoftheSIPrequest.
Table1summarizestheuseofSIPandSIPSURIcomponentsbasedon
thecontextinwhichtheURIappears.Theexternalcolumndescribes
URIsappearinganywhereoutsideofaSIPmessage,forinstanceona
webpageorbusinesscard.Entriesmarked"m"aremandatory,those
marked"o"areoptional,andthosemarked"-"arenotallowed.
ElementsprocessingURIsSHOULDignoreanydisallowedcomponentsif
theyarepresent.Thesecondcolumnindicatesthedefaultvalueof
anoptionalelementifitisnotpresent."--"indicatesthatthe
elementiseithernotoptional,orhasnodefaultvalue.
URIsinContactheaderfieldshavedifferentrestrictionsdepending
onthecontextinwhichtheheaderfieldappears.Onesetappliesto
messagesthatestablishandmaintaindialogs(INVITEandits200(OK)
response).Theotherappliestoregistrationandredirection
messages(REGISTER,its200(OK)response,and3xxclassresponsesto
anymethod).
Rosenberg,et.al.StandardsTrack[Page151]
RFC3261SIP:SessionInitiationProtocolJune2002
19.1.2CharacterEscapingRequirements
dialog
reg./redir.Contact/
defaultReq.-URIToFromContactR-R/Routeexternal
user--oooooo
password--oooooo
host--mmmmmm
port(1)o--ooo
user-paramipoooooo
methodINVITE-----o
maddr-param--o--ooo
ttl-param1o--o-o
transp.-param(2)o--ooo
lr-param--o---oo
other-param--oooooo
headers-----o-o
(1):Thedefaultportvalueistransportandschemedependent.The
defaultis5060forsip:usingUDP,TCP,orSCTP.Thedefaultis
5061forsip:usingTLSoverTCPandsips:overTCP.
(2):Thedefaulttransportisschemedependent.Forsip:,itisUDP.
Forsips:,itisTCP.
Table1:UseanddefaultvaluesofURIcomponentsforSIPheader
fieldvalues,Request-URIandreferences
SIPfollowstherequirementsandguidelinesofRFC2396[5]when
definingthesetofcharactersthatmustbeescapedinaSIPURI,and
usesits""%"HEXHEX"mechanismforescaping.FromRFC2396[5]:
ThesetofcharactersactuallyreservedwithinanygivenURI
componentisdefinedbythatcomponent.Ingeneral,acharacter
isreservedifthesemanticsoftheURIchangesifthecharacter
isreplacedwithitsescapedUS-ASCIIencoding[5].ExcludedUS-
ASCIIcharacters(RFC2396[5]),suchasspaceandcontrol
charactersandcharactersusedasURIdelimiters,alsoMUSTbe
escaped.URIsMUSTNOTcontainunescapedspaceandcontrol
characters.
Foreachcomponent,thesetofvalidBNFexpansionsdefinesexactly
whichcharactersmayappearunescaped.AllothercharactersMUSTbe
escaped.
Forexample,"@"isnotinthesetofcharactersintheuser
component,sotheuser"j@s0n"musthaveatleastthe@signencoded,
asin"j%40s0n".
Rosenberg,et.al.StandardsTrack[Page152]
RFC3261SIP:SessionInitiationProtocolJune2002
ExpandingthehnameandhvaluetokensinSection25showthatallURI
reservedcharactersinheaderfieldnamesandvaluesMUSTbeescaped.
Thetelephone-subscribersubsetoftheusercomponenthasspecial
escapingconsiderations.Thesetofcharactersnotreservedinthe
RFC2806[9]descriptionoftelephone-subscribercontainsanumberof
charactersinvarioussyntaxelementsthatneedtobeescapedwhen
usedinSIPURIs.Anycharactersoccurringinatelephone-subscriber
thatdonotappearinanexpansionoftheBNFfortheuserruleMUST
beescaped.
Notethatcharacterescapingisnotallowedinthehostcomponentof
aSIPorSIPSURI(the%characterisnotvalidinitsexpansion).
Thisislikelytochangeinthefutureasrequirementsfor
InternationalizedDomainNamesarefinalized.Current
implementationsMUSTNOTattempttoimproverobustnessbytreating
receivedescapedcharactersinthehostcomponentasliterally
equivalenttotheirunescapedcounterpart.Thebehaviorrequiredto
meettherequirementsofIDNmaybesignificantlydifferent.
19.1.3ExampleSIPandSIPSURIs
sip:[email protected]
sip:alice:[email protected];transport=tcp
sips:[email protected]?subject=project%20x&priority=urgent
sip:+1-212-555-1212:[email protected];user=phone
sips:[email protected]
sip:[email protected]
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
sip:alice;[email protected]
ThelastsampleURIabovehasauserfieldvalueof
"alice;day=tuesday".Theescapingrulesdefinedaboveallowa
semicolontoappearunescapedinthisfield.Forthepurposesof
thisprotocol,thefieldisopaque.Thestructureofthatvalueis
onlyusefultotheSIPelementresponsiblefortheresource.
19.1.4URIComparison
Someoperationsinthisspecificationrequiredeterminingwhethertwo
SIPorSIPSURIsareequivalent.Inthisspecification,registrars
needtocomparebindingsinContactURIsinREGISTERrequests(see
Section10.3.).SIPandSIPSURIsarecomparedforequality
accordingtothefollowingrules:
oASIPandSIPSURIareneverequivalent.
Rosenberg,et.al.StandardsTrack[Page153]
RFC3261SIP:SessionInitiationProtocolJune2002
oComparisonoftheuserinfoofSIPandSIPSURIsiscase-
sensitive.Thisincludesuserinfocontainingpasswordsor
formattedastelephone-subscribers.Comparisonofallother
componentsoftheURIiscase-insensitiveunlessexplicitly
definedotherwise.
oTheorderingofparametersandheaderfieldsisnotsignificant
incomparingSIPandSIPSURIs.
oCharactersotherthanthoseinthe"reserved"set(seeRFC2396
[5])areequivalenttotheir""%"HEXHEX"encoding.
oAnIPaddressthatistheresultofaDNSlookupofahostname
doesnotmatchthathostname.
oFortwoURIstobeequal,theuser,password,host,andport
componentsmustmatch.
AURIomittingtheusercomponentwillnotmatchaURIthat
includesone.AURIomittingthepasswordcomponentwillnot
matchaURIthatincludesone.
AURIomittinganycomponentwithadefaultvaluewillnot
matchaURIexplicitlycontainingthatcomponentwithits
defaultvalue.Forinstance,aURIomittingtheoptionalport
componentwillnotmatchaURIexplicitlydeclaringport5060.
Thesameistrueforthetransport-parameter,ttl-parameter,
user-parameter,andmethodcomponents.
Definingsip:user@hosttonotbeequivalentto
sip:user@host:5060isachangefromRFC2543.Whenderiving
addressesfromURIs,equivalentaddressesareexpectedfrom
equivalentURIs.TheURIsip:user@host:5060willalways
resolvetoport5060.TheURIsip:user@hostmayresolveto
otherportsthroughtheDNSSRVmechanismsdetailedin[4].
oURIuri-parametercomponentsarecomparedasfollows:
-Anyuri-parameterappearinginbothURIsmustmatch.
-Auser,ttl,ormethoduri-parameterappearinginonlyone
URInevermatches,evenifitcontainsthedefaultvalue.
-AURIthatincludesanmaddrparameterwillnotmatchaURI
thatcontainsnomaddrparameter.
-Allotheruri-parametersappearinginonlyoneURIare
ignoredwhencomparingtheURIs.
Rosenberg,et.al.StandardsTrack[Page154]
RFC3261SIP:SessionInitiationProtocolJune2002
oURIheadercomponentsareneverignored.Anypresentheader
componentMUSTbepresentinbothURIsandmatchfortheURIs
tomatch.Thematchingrulesaredefinedforeachheaderfield
inSection20.
TheURIswithineachofthefollowingsetsareequivalent:
sip:%[email protected];transport=TCP
sip:[email protected];Transport=tcp
sip:[email protected]
sip:[email protected];newparam=5
sip:[email protected];security=on
sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
sip:[email protected]?subject=project%20x&priority=urgent
sip:[email protected]?priority=urgent&subject=project%20x
TheURIswithineachofthefollowingsetsarenotequivalent:
SIP:[email protected];Transport=udp(differentusernames)
sip:[email protected];Transport=UDP
sip:[email protected](canresolvetodifferentports)
sip:[email protected]:5060
sip:[email protected](canresolvetodifferenttransports)
sip:[email protected];transport=udp
sip:[email protected](canresolvetodifferentportandtransports)
sip:[email protected]:6000;transport=tcp
sip:[email protected](differentheadercomponent)
sip:[email protected]?Subject=next%20meeting
sip:[email protected](eventhoughthat'swhat
sip:[email protected])
Notethatequalityisnottransitive:
osip:[email protected]:[email protected];security=onare
equivalent
osip:[email protected]:[email protected];security=off
areequivalent
Rosenberg,et.al.StandardsTrack[Page155]
RFC3261SIP:SessionInitiationProtocolJune2002
osip:[email protected];security=onand
sip:[email protected];security=offarenotequivalent
19.1.5FormingRequestsfromaURI
Animplementationneedstotakecarewhenformingrequestsdirectly
fromaURI.URIsfrombusinesscards,webpages,andevenfrom
sourcesinsidetheprotocolsuchasregisteredcontactsmaycontain
inappropriateheaderfieldsorbodyparts.
AnimplementationMUSTincludeanyprovidedtransport,maddr,ttl,or
userparameterintheRequest-URIoftheformedrequest.IftheURI
containsamethodparameter,itsvalueMUSTbeusedasthemethodof
therequest.ThemethodparameterMUSTNOTbeplacedinthe
Request-URI.UnknownURIparametersMUSTbeplacedinthemessage's
Request-URI.
AnimplementationSHOULDtreatthepresenceofanyheadersorbody
partsintheURIasadesiretoincludetheminthemessage,and
choosetohonortherequestonaper-componentbasis.
AnimplementationSHOULDNOThonortheseobviouslydangerousheader
fields:From,Call-ID,CSeq,Via,andRecord-Route.
AnimplementationSHOULDNOThonoranyrequestedRouteheaderfield
valuesinordertonotbeusedasanunwittingagentinmalicious
attacks.
AnimplementationSHOULDNOThonorrequeststoincludeheaderfields
thatmaycauseittofalselyadvertiseitslocationorcapabilities.
Theseinclude:Accept,Accept-Encoding,Accept-Language,Allow,
Contact(initsdialogusage),Organization,Supported,andUser-
Agent.
AnimplementationSHOULDverifytheaccuracyofanyrequested
descriptiveheaderfields,including:Content-Disposition,Content-
Encoding,Content-Language,Content-Length,Content-Type,Date,
Mime-Version,andTimestamp.
IftherequestformedfromconstructingamessagefromagivenURIis
notavalidSIPrequest,theURIisinvalid.AnimplementationMUST
NOTproceedwithtransmittingtherequest.Itshouldinsteadpursue
thecourseofactiondueaninvalidURIinthecontextitoccurs.
Theconstructedrequestcanbeinvalidinmanyways.These
include,butarenotlimitedto,syntaxerrorinheaderfields,
invalidcombinationsofURIparameters,oranincorrect
descriptionofthemessagebody.
Rosenberg,et.al.StandardsTrack[Page156]
RFC3261SIP:SessionInitiationProtocolJune2002
SendingarequestformedfromagivenURImayrequirecapabilities
unavailabletotheimplementation.TheURImightindicateuseofan
unimplementedtransportorextension,forexample.Animplementation
SHOULDrefusetosendtheserequestsratherthanmodifyingthemto
matchtheircapabilities.AnimplementationMUSTNOTsendarequest
requiringanextensionthatitdoesnotsupport.
Forexample,sucharequestcanbeformedthroughthepresenceof
aRequireheaderparameteroramethodURIparameterwithan
unknownorexplicitlyunsupportedvalue.
19.1.6RelatingSIPURIsandtelURLs
WhenatelURL(RFC2806[9])isconvertedtoaSIPorSIPSURI,the
entiretelephone-subscriberportionofthetelURL,includingany
parameters,isplacedintotheuserinfopartoftheSIPorSIPSURI.
Thus,tel:+358-555-1234567;postd=pp22becomes
sip:+358-555-1234567;[email protected];user=phone
or
sips:+358-555-1234567;[email protected];user=phone
not
sip:[email protected];postd=pp22;user=phone
or
sips:[email protected];postd=pp22;user=phone
Ingeneral,equivalent"tel"URLsconvertedtoSIPorSIPSURIsin
thisfashionmaynotproduceequivalentSIPorSIPSURIs.The
userinfoofSIPandSIPSURIsarecomparedasacase-sensitive
string.Varianceincase-insensitiveportionsoftelURLsand
reorderingoftelURLparametersdoesnotaffecttelURLequivalence,
butdoesaffecttheequivalenceofSIPURIsformedfromthem.
Forexample,
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
areequivalent,while
sip:+358-555-1234567;[email protected];user=phone
sip:+358-555-1234567;[email protected];user=phone
Rosenberg,et.al.StandardsTrack[Page157]
RFC3261SIP:SessionInitiationProtocolJune2002
arenot.
Likewise,
tel:+358-555-1234567;postd=pp22;isub=1411
tel:+358-555-1234567;isub=1411;postd=pp22
areequivalent,while
sip:+358-555-1234567;postd=pp22;[email protected];user=phone
sip:+358-555-1234567;isub=1411;[email protected];user=phone
arenot.
Tomitigatethisproblem,elementsconstructingtelephone-subscriber
fieldstoplaceintheuserinfopartofaSIPorSIPSURISHOULDfold
anycase-insensitiveportionoftelephone-subscribertolowercase,
andorderthetelephone-subscriberparameterslexicallybyparameter
name,exceptingisdn-subaddressandpost-dial,whichoccurfirstand
inthatorder.(AllcomponentsofatelURLexceptforfuture-
extensionparametersaredefinedtobecomparedcase-insensitive.)
Followingthissuggestion,both
tel:+358-555-1234567;postd=pp22
tel:+358-555-1234567;POSTD=PP22
become
sip:+358-555-1234567;[email protected];user=phone
andboth
tel:+358-555-1234567;tsp=a.b;phone-context=5
tel:+358-555-1234567;phone-context=5;tsp=a.b
become
sip:+358-555-1234567;phone-context=5;[email protected];user=phone
19.2OptionTags
Optiontagsareuniqueidentifiersusedtodesignatenewoptions
(extensions)inSIP.ThesetagsareusedinRequire(Section20.32),
Proxy-Require(Section20.29),Supported(Section20.37)and
Unsupported(Section20.40)headerfields.Notethattheseoptions
appearasparametersinthoseheaderfieldsinanoption-tag=token
form(seeSection25forthedefinitionoftoken).
Rosenberg,et.al.StandardsTrack[Page158]
RFC3261SIP:SessionInitiationProtocolJune2002
OptiontagsaredefinedinstandardstrackRFCs.Thisisachange
frompastpractice,andisinstitutedtoensurecontinuingmulti-
vendorinteroperability(seediscussioninSection20.32andSection
20.37).AnIANAregistryofoptiontagsisusedtoensureeasy
reference.
19.3Tags
The"tag"parameterisusedintheToandFromheaderfieldsofSIP
messages.Itservesasageneralmechanismtoidentifyadialog,
whichisthecombinationoftheCall-IDalongwithtwotags,onefrom
eachparticipantinthedialog.WhenaUAsendsarequestoutsideof
adialog,itcontainsaFromtagonly,providing"half"ofthedialog
ID.Thedialogiscompletedfromtheresponse(s),eachofwhich
contributesthesecondhalfintheToheaderfield.Theforkingof
SIPrequestsmeansthatmultipledialogscanbeestablishedfroma
singlerequest.Thisalsoexplainstheneedforthetwo-sideddialog
identifier;withoutacontributionfromtherecipients,the
originatorcouldnotdisambiguatethemultipledialogsestablished
fromasinglerequest.
WhenatagisgeneratedbyaUAforinsertionintoarequestor
response,itMUSTbegloballyuniqueandcryptographicallyrandom
withatleast32bitsofrandomness.Apropertyofthisselection
requirementisthataUAwillplaceadifferenttagintotheFrom
headerofanINVITEthanitwouldplaceintotheToheaderofthe
responsetothesameINVITE.ThisisneededinorderforaUAto
inviteitselftoasession,acommoncasefor"hairpinning"ofcalls
inPSTNgateways.Similarly,twoINVITEsfordifferentcallswill
havedifferentFromtags,andtworesponsesfordifferentcallswill
havedifferentTotags.
Besidestherequirementforglobaluniqueness,thealgorithmfor
generatingatagisimplementation-specific.Tagsarehelpfulin
faulttolerantsystems,whereadialogistoberecoveredonan
alternateserverafterafailure.AUAScanselectthetaginsucha
waythatabackupcanrecognizearequestaspartofadialogonthe
failedserver,andthereforedeterminethatitshouldattemptto
recoverthedialogandanyotherstateassociatedwithit.
20HeaderFields
ThegeneralsyntaxforheaderfieldsiscoveredinSection7.3.This
sectionliststhefullsetofheaderfieldsalongwithnoteson
syntax,meaning,andusage.Throughoutthissection,weuse[HX.Y]
torefertoSectionX.YofthecurrentHTTP/1.1specificationRFC
2616[8].Examplesofeachheaderfieldaregiven.
Rosenberg,et.al.StandardsTrack[Page159]
RFC3261SIP:SessionInitiationProtocolJune2002
Informationaboutheaderfieldsinrelationtomethodsandproxy
processingissummarizedinTables2and3.
The"where"columndescribestherequestandresponsetypesinwhich
theheaderfieldcanbeused.Valuesinthiscolumnare:
R:headerfieldmayonlyappearinrequests;
r:headerfieldmayonlyappearinresponses;
2xx,4xx,etc.:Anumericalvalueorrangeindicatesresponse
codeswithwhichtheheaderfieldcanbeused;
c:headerfieldiscopiedfromtherequesttotheresponse.
Anemptyentryinthe"where"columnindicatesthattheheader
fieldmaybepresentinallrequestsandresponses.
The"proxy"columndescribestheoperationsaproxymayperformona
headerfield:
a:Aproxycanaddorconcatenatetheheaderfieldifnotpresent.
m:Aproxycanmodifyanexistingheaderfieldvalue.
d:Aproxycandeleteaheaderfieldvalue.
r:Aproxymustbeabletoreadtheheaderfield,andthusthis
headerfieldcannotbeencrypted.
Thenextsixcolumnsrelatetothepresenceofaheaderfieldina
method:
c:Conditional;requirementsontheheaderfielddependonthe
contextofthemessage.
m:Theheaderfieldismandatory.
m*:TheheaderfieldSHOULDbesent,butclients/serversneedto
bepreparedtoreceivemessageswithoutthatheaderfield.
o:Theheaderfieldisoptional.
t:TheheaderfieldSHOULDbesent,butclients/serversneedtobe
preparedtoreceivemessageswithoutthatheaderfield.
Ifastream-basedprotocol(suchasTCP)isusedasa
transport,thentheheaderfieldMUSTbesent.
Rosenberg,et.al.StandardsTrack[Page160]
RFC3261SIP:SessionInitiationProtocolJune2002
*:Theheaderfieldisrequiredifthemessagebodyisnotempty.
SeeSections20.14,20.15and7.4fordetails.
-:Theheaderfieldisnotapplicable.
"Optional"meansthatanelementMAYincludetheheaderfieldina
requestorresponse,andaUAMAYignoretheheaderfieldifpresent
intherequestorresponse(TheexceptiontothisruleistheRequire
headerfielddiscussedin20.32).A"mandatory"headerfieldMUSTbe
presentinarequest,andMUSTbeunderstoodbytheUASreceivingthe
request.AmandatoryresponseheaderfieldMUSTbepresentinthe
response,andtheheaderfieldMUSTbeunderstoodbytheUAC
processingtheresponse."Notapplicable"meansthattheheader
fieldMUSTNOTbepresentinarequest.Ifoneisplacedina
requestbymistake,itMUSTbeignoredbytheUASreceivingthe
request.Similarly,aheaderfieldlabeled"notapplicable"fora
responsemeansthattheUASMUSTNOTplacetheheaderfieldinthe
response,andtheUACMUSTignoretheheaderfieldintheresponse.
AUASHOULDignoreextensionheaderparametersthatarenot
understood.
Acompactformofsomecommonheaderfieldnamesisalsodefinedfor
usewhenoverallmessagesizeisanissue.
TheContact,From,andToheaderfieldscontainaURI.IftheURI
containsacomma,questionmarkorsemicolon,theURIMUSTbe
enclosedinanglebrackets().AnyURIparametersare
containedwithinthesebrackets.IftheURIisnotenclosedinangle
brackets,anysemicolon-delimitedparametersareheader-parameters,
notURIparameters.
20.1Accept
TheAcceptheaderfieldfollowsthesyntaxdefinedin[H14.1].The
semanticsarealsoidentical,withtheexceptionthatifnoAccept
headerfieldispresent,theserverSHOULDassumeadefaultvalueof
application/sdp.
AnemptyAcceptheaderfieldmeansthatnoformatsareacceptable.
Rosenberg,et.al.StandardsTrack[Page161]
RFC3261SIP:SessionInitiationProtocolJune2002
Example:
HeaderfieldwhereproxyACKBYECANINVOPTREG
___________________________________________________________
AcceptR-o-om*o
Accept2xx---om*o
Accept415-c-ccc
Accept-EncodingR-o-ooo
Accept-Encoding2xx---om*o
Accept-Encoding415-c-ccc
Accept-LanguageR-o-ooo
Accept-Language2xx---om*o
Accept-Language415-c-ccc
Alert-InfoRar---o--
Alert-Info180ar---o--
AllowR-o-ooo
Allow2xx-o-m*m*o
Allowr-o-ooo
Allow405-m-mmm
Authentication-Info2xx-o-ooo
AuthorizationRoooooo
Call-IDcrmmmmmm
Call-Infoar---ooo
ContactRo--moo
Contact1xx---o--
Contact2xx---moo
Contact3xxd-o-ooo
Contact485-o-ooo
Content-Dispositionoo-ooo
Content-Encodingoo-ooo
Content-Languageoo-ooo
Content-Lengthartttttt
Content-Type**-***
CSeqcrmmmmmm
Dateaoooooo
Error-Info300-699a-ooooo
Expires---o-o
Fromcrmmmmmm
In-Reply-ToR---o--
Max-ForwardsRamrmmmmmm
Min-Expires423-----m
MIME-Versionoo-ooo
Organizationar---ooo
Table2:Summaryofheaderfields,A--O
Rosenberg,et.al.StandardsTrack[Page162]
RFC3261SIP:SessionInitiationProtocolJune2002
HeaderfieldwhereproxyACKBYECANINVOPTREG
___________________________________________________________________
PriorityRar---o--
Proxy-Authenticate407ar-m-mmm
Proxy-Authenticate401ar-ooooo
Proxy-AuthorizationRdroo-ooo
Proxy-RequireRar-o-ooo
Record-RouteRarooooo-
Record-Route2xx,18xmr-oooo-
Reply-To---o--
Requirear-c-ccc
Retry-After404,413,480,486-ooooo
500,503-ooooo
600,603-ooooo
RouteRadrcccccc
Serverr-ooooo
SubjectR---o--
SupportedR-oom*oo
Supported2xx-oom*m*o
Timestampoooooo
Toc(1)rmmmmmm
Unsupported420-m-mmm
User-Agentoooooo
ViaRamrmmmmmm
Viarcdrmmmmmm
Warningr-ooooo
WWW-Authenticate401ar-m-mmm
WWW-Authenticate407ar-o-ooo
Table3:Summaryofheaderfields,P--Z;(1):copiedwithpossible
additionoftag
Accept:application/sdp;level=1,application/x-private,text/html
20.2Accept-Encoding
TheAccept-EncodingheaderfieldissimilartoAccept,butrestricts
thecontent-codings[H3.5]thatareacceptableintheresponse.See
[H14.3].ThesemanticsinSIPareidenticaltothosedefinedin
[H14.3].
AnemptyAccept-Encodingheaderfieldispermissible.Itis
equivalenttoAccept-Encoding:identity,thatis,onlytheidentity
encoding,meaningnoencoding,ispermissible.
IfnoAccept-Encodingheaderfieldispresent,theserverSHOULD
assumeadefaultvalueofidentity.
Rosenberg,et.al.StandardsTrack[Page163]
RFC3261SIP:SessionInitiationProtocolJune2002
ThisdiffersslightlyfromtheHTTPdefinition,whichindicatesthat
whennotpresent,anyencodingcanbeused,buttheidentityencoding
ispreferred.
Example:
Accept-Encoding:gzip
20.3Accept-Language
TheAccept-Languageheaderfieldisusedinrequeststoindicatethe
preferredlanguagesforreasonphrases,sessiondescriptions,or
statusresponsescarriedasmessagebodiesintheresponse.Ifno
Accept-Languageheaderfieldispresent,theserverSHOULDassumeall
languagesareacceptabletotheclient.
TheAccept-Languageheaderfieldfollowsthesyntaxdefinedin
[H14.4].Therulesfororderingthelanguagesbasedonthe"q"
parameterapplytoSIPaswell.
Example:
Accept-Language:da,en-gb;q=0.8,en;q=0.7
20.4Alert-Info
WhenpresentinanINVITErequest,theAlert-Infoheaderfield
specifiesanalternativeringtonetotheUAS.Whenpresentina180
(Ringing)response,theAlert-Infoheaderfieldspecifiesan
alternativeringbacktonetotheUAC.Atypicalusageisforaproxy
toinsertthisheaderfieldtoprovideadistinctiveringfeature.
TheAlert-Infoheaderfieldcanintroducesecurityrisks.These
risksandthewaystohandlethemarediscussedinSection20.9,
whichdiscussestheCall-Infoheaderfieldsincetherisksare
identical.
Inaddition,auserSHOULDbeabletodisablethisfeature
selectively.
Thishelpspreventdisruptionsthatcouldresultfromtheuseof
thisheaderfieldbyuntrustedelements.
Example:
Alert-Info:
Rosenberg,et.al.StandardsTrack[Page164]
RFC3261SIP:SessionInitiationProtocolJune2002
20.5Allow
TheAllowheaderfieldliststhesetofmethodssupportedbytheUA
generatingthemessage.
Allmethods,includingACKandCANCEL,understoodbytheUAMUSTbe
includedinthelistofmethodsintheAllowheaderfield,when
present.TheabsenceofanAllowheaderfieldMUSTNOTbe
interpretedtomeanthattheUAsendingthemessagesupportsno
methods.Rather,itimpliesthattheUAisnotprovidingany
informationonwhatmethodsitsupports.
SupplyinganAllowheaderfieldinresponsestomethodsotherthan
OPTIONSreducesthenumberofmessagesneeded.
Example:
Allow:INVITE,ACK,OPTIONS,CANCEL,BYE
20.6Authentication-Info
TheAuthentication-Infoheaderfieldprovidesformutual
authenticationwithHTTPDigest.AUASMAYincludethisheaderfield
ina2xxresponsetoarequestthatwassuccessfullyauthenticated
usingdigestbasedontheAuthorizationheaderfield.
SyntaxandsemanticsfollowthosespecifiedinRFC2617[17].
Example:
Authentication-Info:nextnonce="47364c23432d2e131a5fb210812c"
20.7Authorization
TheAuthorizationheaderfieldcontainsauthenticationcredentialsof
aUA.Section22.2overviewstheuseoftheAuthorizationheader
field,andSection22.4describesthesyntaxandsemanticswhenused
withHTTPauthentication.
Thisheaderfield,alongwithProxy-Authorization,breaksthegeneral
rulesaboutmultipleheaderfieldvalues.Althoughnotacomma-
separatedlist,thisheaderfieldnamemaybepresentmultipletimes,
andMUSTNOTbecombinedintoasingleheaderlineusingtheusual
rulesdescribedinSection7.3.
Rosenberg,et.al.StandardsTrack[Page165]
RFC3261SIP:SessionInitiationProtocolJune2002
Intheexamplebelow,therearenoquotesaroundtheDigest
parameter:
Authorization:Digestusername="Alice",realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
20.8Call-ID
TheCall-IDheaderfielduniquelyidentifiesaparticularinvitation
orallregistrationsofaparticularclient.Asinglemultimedia
conferencecangiverisetoseveralcallswithdifferentCall-IDs,
forexample,ifauserinvitesasingleindividualseveraltimesto
thesame(long-running)conference.Call-IDsarecase-sensitiveand
aresimplycomparedbyte-by-byte.
ThecompactformoftheCall-IDheaderfieldisi.
Examples:
Call-ID:[email protected]
i:[email protected]
20.9Call-Info
TheCall-Infoheaderfieldprovidesadditionalinformationaboutthe
callerorcallee,dependingonwhetheritisfoundinarequestor
response.ThepurposeoftheURIisdescribedbythe"purpose"
parameter.The"icon"parameterdesignatesanimagesuitableasan
iconicrepresentationofthecallerorcallee.The"info"parameter
describesthecallerorcalleeingeneral,forexample,throughaweb
page.The"card"parameterprovidesabusinesscard,forexample,in
vCard[36]orLDIF[37]formats.Additionaltokenscanberegistered
usingIANAandtheproceduresinSection27.
UseoftheCall-Infoheaderfieldcanposeasecurityrisk.Ifa
calleefetchestheURIsprovidedbyamaliciouscaller,thecallee
maybeatriskfordisplayinginappropriateoroffensivecontent,
dangerousorillegalcontent,andsoon.Therefore,itis
RECOMMENDEDthataUAonlyrendertheinformationintheCall-Info
headerfieldifitcanverifytheauthenticityoftheelementthat
originatedtheheaderfieldandtruststhatelement.Thisneednot
bethepeerUA;aproxycaninsertthisheaderfieldintorequests.
Example:
Call-Info:;purpose=icon,
;purpose=info
Rosenberg,et.al.StandardsTrack[Page166]
RFC3261SIP:SessionInitiationProtocolJune2002
20.10Contact
AContactheaderfieldvalueprovidesaURIwhosemeaningdependson
thetypeofrequestorresponseitisin.
AContactheaderfieldvaluecancontainadisplayname,aURIwith
URIparameters,andheaderparameters.
ThisdocumentdefinestheContactparameters"q"and"expires".
TheseparametersareonlyusedwhentheContactispresentina
REGISTERrequestorresponse,orina3xxresponse.Additional
parametersmaybedefinedinotherspecifications.
Whentheheaderfieldvaluecontainsadisplayname,theURI
includingallURIparametersisenclosedin"".Ifno""arepresent,allparametersaftertheURIareheader
parameters,notURIparameters.Thedisplaynamecanbetokens,ora
quotedstring,ifalargercharactersetisdesired.
Evenifthe"display-name"isempty,the"name-addr"formMUSTbe
usedifthe"addr-spec"containsacomma,semicolon,orquestion
mark.TheremayormaynotbeLWSbetweenthedisplay-nameandthe
"
;q=0.7;expires=3600,
"Mr.Watson";q=0.1
m:;expires=60
Rosenberg,et.al.StandardsTrack[Page167]
RFC3261SIP:SessionInitiationProtocolJune2002
20.11Content-Disposition
TheContent-Dispositionheaderfielddescribeshowthemessagebody
or,formultipartmessages,amessagebodypartistobeinterpreted
bytheUACorUAS.ThisSIPheaderfieldextendstheMIMEContent-
Type(RFC2183[18]).
Severalnew"disposition-types"oftheContent-Dispositionheaderare
definedbySIP.Thevalue"session"indicatesthatthebodypart
describesasession,foreithercallsorearly(pre-call)media.The
value"render"indicatesthatthebodypartshouldbedisplayedor
otherwiserenderedtotheuser.Notethatthevalue"render"isused
ratherthan"inline"toavoidtheconnotationthattheMIMEbodyis
displayedasapartoftherenderingoftheentiremessage(sincethe
MIMEbodiesofSIPmessagesoftentimesarenotdisplayedtousers).
Forbackward-compatibility,iftheContent-Dispositionheaderfield
ismissing,theserverSHOULDassumebodiesofContent-Type
application/sdparethedisposition"session",whileothercontent
typesare"render".
Thedispositiontype"icon"indicatesthatthebodypartcontainsan
imagesuitableasaniconicrepresentationofthecallerorcallee
thatcouldberenderedinformationallybyauseragentwhenamessage
hasbeenreceived,orpersistentlywhileadialogtakesplace.The
value"alert"indicatesthatthebodypartcontainsinformation,such
asanaudioclip,thatshouldberenderedbytheuseragentinan
attempttoalerttheusertothereceiptofarequest,generallya
requestthatinitiatesadialog;thisalertingbodycouldforexample
berenderedasaringtoneforaphonecallaftera180Ringing
provisionalresponsehasbeensent.
AnyMIMEbodywitha"disposition-type"thatrenderscontenttothe
usershouldonlybeprocessedwhenamessagehasbeenproperly
authenticated.
Thehandlingparameter,handling-param,describeshowtheUASshould
reactifitreceivesamessagebodywhosecontenttypeordisposition
typeitdoesnotunderstand.Theparameterhasdefinedvaluesof
"optional"and"required".Ifthehandlingparameterismissing,the
value"required"SHOULDbeassumed.Thehandlingparameteris
describedinRFC3204[19].
Ifthisheaderfieldismissing,theMIMEtypedeterminesthedefault
contentdisposition.Ifthereisnone,"render"isassumed.
Example:
Content-Disposition:session
Rosenberg,et.al.StandardsTrack[Page168]
RFC3261SIP:SessionInitiationProtocolJune2002
20.12Content-Encoding
TheContent-Encodingheaderfieldisusedasamodifiertothe
"media-type".Whenpresent,itsvalueindicateswhatadditional
contentcodingshavebeenappliedtotheentity-body,andthuswhat
decodingmechanismsMUSTbeappliedinordertoobtainthemedia-type
referencedbytheContent-Typeheaderfield.Content-Encodingis
primarilyusedtoallowabodytobecompressedwithoutlosingthe
identityofitsunderlyingmediatype.
Ifmultipleencodingshavebeenappliedtoanentity-body,the
contentcodingsMUSTbelistedintheorderinwhichtheywere
applied.
Allcontent-codingvaluesarecase-insensitive.IANAactsasa
registryforcontent-codingvaluetokens.See[H3.5]fora
definitionofthesyntaxforcontent-coding.
ClientsMAYapplycontentencodingstothebodyinrequests.A
serverMAYapplycontentencodingstothebodiesinresponses.The
serverMUSTonlyuseencodingslistedintheAccept-Encodingheader
fieldintherequest.
ThecompactformoftheContent-Encodingheaderfieldise.
Examples:
Content-Encoding:gzip
e:tar
20.13Content-Language
See[H14.12].Example:
Content-Language:fr
20.14Content-Length
TheContent-Lengthheaderfieldindicatesthesizeofthemessage-
body,indecimalnumberofoctets,senttotherecipient.
ApplicationsSHOULDusethisfieldtoindicatethesizeofthe
message-bodytobetransferred,regardlessofthemediatypeofthe
entity.Ifastream-basedprotocol(suchasTCP)isusedas
transport,theheaderfieldMUSTbeused.
Thesizeofthemessage-bodydoesnotincludetheCRLFseparating
headerfieldsandbody.AnyContent-Lengthgreaterthanorequalto
zeroisavalidvalue.Ifnobodyispresentinamessage,thenthe
Content-LengthheaderfieldvalueMUSTbesettozero.
Rosenberg,et.al.StandardsTrack[Page169]
RFC3261SIP:SessionInitiationProtocolJune2002
TheabilitytoomitContent-Lengthsimplifiesthecreationof
cgi-likescriptsthatdynamicallygenerateresponses.
Thecompactformoftheheaderfieldisl.
Examples:
Content-Length:349
l:173
20.15Content-Type
TheContent-Typeheaderfieldindicatesthemediatypeofthe
message-bodysenttotherecipient.The"media-type"elementis
definedin[H3.7].TheContent-TypeheaderfieldMUSTbepresentif
thebodyisnotempty.Ifthebodyisempty,andaContent-Type
headerfieldispresent,itindicatesthatthebodyofthespecific
typehaszerolength(forexample,anemptyaudiofile).
Thecompactformoftheheaderfieldisc.
Examples:
Content-Type:application/sdp
c:text/html;charset=ISO-8859-4
20.16CSeq
ACSeqheaderfieldinarequestcontainsasingledecimalsequence
numberandtherequestmethod.ThesequencenumberMUSTbe
expressibleasa32-bitunsignedinteger.ThemethodpartofCSeqis
case-sensitive.TheCSeqheaderfieldservestoordertransactions
withinadialog,toprovideameanstouniquelyidentify
transactions,andtodifferentiatebetweennewrequestsandrequest
retransmissions.TwoCSeqheaderfieldsareconsideredequalifthe
sequencenumberandtherequestmethodareidentical.Example:
CSeq:4711INVITE
20.17Date
TheDateheaderfieldcontainsthedateandtime.UnlikeHTTP/1.1,
SIPonlysupportsthemostrecentRFC1123[20]formatfordates.As
in[H3.3],SIPrestrictsthetimezoneinSIP-dateto"GMT",while
RFC1123allowsanytimezone.AnRFC1123dateiscase-sensitive.
TheDateheaderfieldreflectsthetimewhentherequestorresponse
isfirstsent.
Rosenberg,et.al.StandardsTrack[Page170]
RFC3261SIP:SessionInitiationProtocolJune2002
TheDateheaderfieldcanbeusedbysimpleendsystemswithouta
battery-backedclocktoacquireanotionofcurrenttime.
However,initsGMTform,itrequiresclientstoknowtheiroffset
fromGMT.
Example:
Date:Sat,13Nov201023:29:00GMT
20.18Error-Info
TheError-Infoheaderfieldprovidesapointertoadditional
informationabouttheerrorstatusresponse.
SIPUACshaveuserinterfacecapabilitiesrangingfrompop-up
windowsandaudioonPCsoftclientstoaudio-onlyon"black"
phonesorendpointsconnectedviagateways.Ratherthanforcinga
servergeneratinganerrortochoosebetweensendinganerror
statuscodewithadetailedreasonphraseandplayinganaudio
recording,theError-Infoheaderfieldallowsbothtobesent.
TheUACthenhasthechoiceofwhicherrorindicatortorenderto
thecaller.
AUACMAYtreataSIPorSIPSURIinanError-Infoheaderfieldasif
itwereaContactinaredirectandgenerateanewINVITE,resulting
inarecordedannouncementsessionbeingestablished.Anon-SIPURI
MAYberenderedtotheuser.
Examples:
SIP/2.0404Thenumberyouhavedialedisnotinservice
Error-Info:
20.19Expires
TheExpiresheaderfieldgivestherelativetimeafterwhichthe
message(orcontent)expires.
Theprecisemeaningofthisismethoddependent.
TheexpirationtimeinanINVITEdoesnotaffectthedurationofthe
actualsessionthatmayresultfromtheinvitation.Session
descriptionprotocolsmayoffertheabilitytoexpresstimelimitson
thesessionduration,however.
Thevalueofthisfieldisanintegralnumberofseconds(indecimal)
between0and(2**32)-1,measuredfromthereceiptoftherequest.
Rosenberg,et.al.StandardsTrack[Page171]
RFC3261SIP:SessionInitiationProtocolJune2002
Example:
Expires:5
20.20From
TheFromheaderfieldindicatestheinitiatoroftherequest.This
maybedifferentfromtheinitiatorofthedialog.Requestssentby
thecalleetothecallerusethecallee'saddressintheFromheader
field.
Theoptional"display-name"ismeanttoberenderedbyahumanuser
interface.AsystemSHOULDusethedisplayname"Anonymous"ifthe
identityoftheclientistoremainhidden.Evenifthe"display-
name"isempty,the"name-addr"formMUSTbeusedifthe"addr-spec"
containsacomma,questionmark,orsemicolon.Syntaxissuesare
discussedinSection7.3.1.
TwoFromheaderfieldsareequivalentiftheirURIsmatch,andtheir
parametersmatch.Extensionparametersinoneheaderfield,not
presentintheotherareignoredforthepurposesofcomparison.This
meansthatthedisplaynameandpresenceorabsenceofanglebrackets
donotaffectmatching.
SeeSection20.10fortherulesforparsingadisplayname,URIand
URIparameters,andheaderfieldparameters.
ThecompactformoftheFromheaderfieldisf.
Examples:
From:"A.G.Bell";tag=a48s
From:sip:[email protected];tag=887s
f:Anonymous;tag=hyh8
20.21In-Reply-To
TheIn-Reply-ToheaderfieldenumeratestheCall-IDsthatthiscall
referencesorreturns.TheseCall-IDsmayhavebeencachedbythe
clientthenincludedinthisheaderfieldinareturncall.
Thisallowsautomaticcalldistributionsystemstoroutereturn
callstotheoriginatorofthefirstcall.Thisalsoallows
calleestofiltercalls,sothatonlyreturncallsforcallsthey
originatedwillbeaccepted.Thisfieldisnotasubstitutefor
requestauthentication.
Rosenberg,et.al.StandardsTrack[Page172]
RFC3261SIP:SessionInitiationProtocolJune2002
Example:
In-Reply-To:[email protected],[email protected]
20.22Max-Forwards
TheMax-ForwardsheaderfieldmustbeusedwithanySIPmethodto
limitthenumberofproxiesorgatewaysthatcanforwardtherequest
tothenextdownstreamserver.Thiscanalsobeusefulwhenthe
clientisattemptingtotracearequestchainthatappearstobe
failingorloopinginmid-chain.
TheMax-Forwardsvalueisanintegerintherange0-255indicating
theremainingnumberoftimesthisrequestmessageisallowedtobe
forwarded.Thiscountisdecrementedbyeachserverthatforwards
therequest.Therecommendedinitialvalueis70.
Thisheaderfieldshouldbeinsertedbyelementsthatcannot
otherwiseguaranteeloopdetection.Forexample,aB2BUAshould
insertaMax-Forwardsheaderfield.
Example:
Max-Forwards:6
20.23Min-Expires
TheMin-Expiresheaderfieldconveystheminimumrefreshinterval
supportedforsoft-stateelementsmanagedbythatserver.This
includesContactheaderfieldsthatarestoredbyaregistrar.The
headerfieldcontainsadecimalintegernumberofsecondsfrom0to
(2**32)-1.Theuseoftheheaderfieldina423(IntervalTooBrief)
responseisdescribedinSections10.2.8,10.3,and21.4.17.
Example:
Min-Expires:60
20.24MIME-Version
See[H19.4.1].
Example:
MIME-Version:1.0
Rosenberg,et.al.StandardsTrack[Page173]
RFC3261SIP:SessionInitiationProtocolJune2002
20.25Organization
TheOrganizationheaderfieldconveysthenameoftheorganizationto
whichtheSIPelementissuingtherequestorresponsebelongs.
ThefieldMAYbeusedbyclientsoftwaretofiltercalls.
Example:
Organization:BoxesbyBob
20.26Priority
ThePriorityheaderfieldindicatestheurgencyoftherequestas
perceivedbytheclient.ThePriorityheaderfielddescribesthe
prioritythattheSIPrequestshouldhavetothereceivinghumanor
itsagent.Forexample,itmaybefactoredintodecisionsaboutcall
routingandacceptance.Forthesedecisions,amessagecontainingno
PriorityheaderfieldSHOULDbetreatedasifitspecifiedaPriority
of"normal".ThePriorityheaderfielddoesnotinfluencetheuseof
communicationsresourcessuchaspacketforwardingpriorityin
routersoraccesstocircuitsinPSTNgateways.Theheaderfieldcan
havethevalues"non-urgent","normal","urgent",and"emergency",
butadditionalvaluescanbedefinedelsewhere.ItisRECOMMENDED
thatthevalueof"emergency"onlybeusedwhenlife,limb,or
propertyareinimminentdanger.Otherwise,therearenosemantics
definedforthisheaderfield.
ThesearethevaluesofRFC2076[38],withtheadditionof
"emergency".
Examples:
Subject:Atornadoisheadingourway!
Priority:emergency
or
Subject:Weekendplans
Priority:non-urgent
20.27Proxy-Authenticate
AProxy-Authenticateheaderfieldvaluecontainsanauthentication
challenge.
Theuseofthisheaderfieldisdefinedin[H14.33].SeeSection
22.3forfurtherdetailsonitsusage.
Rosenberg,et.al.StandardsTrack[Page174]
RFC3261SIP:SessionInitiationProtocolJune2002
Example:
Proxy-Authenticate:Digestrealm="atlanta.com",
domain="sip:ss1.carrier.com",qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="",stale=FALSE,algorithm=MD5
20.28Proxy-Authorization
TheProxy-Authorizationheaderfieldallowstheclienttoidentify
itself(oritsuser)toaproxythatrequiresauthentication.A
Proxy-Authorizationfieldvalueconsistsofcredentialscontaining
theauthenticationinformationoftheuseragentfortheproxyand/or
realmoftheresourcebeingrequested.
SeeSection22.3foradefinitionoftheusageofthisheaderfield.
Thisheaderfield,alongwithAuthorization,breaksthegeneralrules
aboutmultipleheaderfieldnames.Althoughnotacomma-separated
list,thisheaderfieldnamemaybepresentmultipletimes,andMUST
NOTbecombinedintoasingleheaderlineusingtheusualrules
describedinSection7.3.1.
Example:
Proxy-Authorization:Digestusername="Alice",realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"
20.29Proxy-Require
TheProxy-Requireheaderfieldisusedtoindicateproxy-sensitive
featuresthatmustbesupportedbytheproxy.SeeSection20.32for
moredetailsonthemechanicsofthismessageandausageexample.
Example:
Proxy-Require:foo
20.30Record-Route
TheRecord-Routeheaderfieldisinsertedbyproxiesinarequestto
forcefuturerequestsinthedialogtoberoutedthroughtheproxy.
ExamplesofitsusewiththeRouteheaderfieldaredescribedin
Sections16.12.1.
Rosenberg,et.al.StandardsTrack[Page175]
RFC3261SIP:SessionInitiationProtocolJune2002
Example:
Record-Route:,
20.31Reply-To
TheReply-ToheaderfieldcontainsalogicalreturnURIthatmaybe
differentfromtheFromheaderfield.Forexample,theURIMAYbe
usedtoreturnmissedcallsorunestablishedsessions.Iftheuser
wishedtoremainanonymous,theheaderfieldSHOULDeitherbeomitted
fromtherequestorpopulatedinsuchawaythatdoesnotrevealany
privateinformation.
Evenifthe"display-name"isempty,the"name-addr"formMUSTbe
usedifthe"addr-spec"containsacomma,questionmark,or
semicolon.SyntaxissuesarediscussedinSection7.3.1.
Example:
Reply-To:Bob
20.32Require
TheRequireheaderfieldisusedbyUACstotellUASsaboutoptions
thattheUACexpectstheUAStosupportinordertoprocessthe
request.Althoughanoptionalheaderfield,theRequireMUSTNOTbe
ignoredifitispresent.
TheRequireheaderfieldcontainsalistofoptiontags,describedin
Section19.2.EachoptiontagdefinesaSIPextensionthatMUSTbe
understoodtoprocesstherequest.Frequently,thisisusedto
indicatethataspecificsetofextensionheaderfieldsneedtobe
understood.AUACcomplianttothisspecificationMUSTonlyinclude
optiontagscorrespondingtostandards-trackRFCs.
Example:
Require:100rel
20.33Retry-After
TheRetry-Afterheaderfieldcanbeusedwitha500(ServerInternal
Error)or503(ServiceUnavailable)responsetoindicatehowlongthe
serviceisexpectedtobeunavailabletotherequestingclientand
witha404(NotFound),413(RequestEntityTooLarge),480
(TemporarilyUnavailable),486(BusyHere),600(Busy),or603
Rosenberg,et.al.StandardsTrack[Page176]
RFC3261SIP:SessionInitiationProtocolJune2002
(Decline)responsetoindicatewhenthecalledpartyanticipates
beingavailableagain.Thevalueofthisfieldisapositiveinteger
numberofseconds(indecimal)afterthetimeoftheresponse.
Anoptionalcommentcanbeusedtoindicateadditionalinformation
aboutthetimeofcallback.Anoptional"duration"parameter
indicateshowlongthecalledpartywillbereachablestartingatthe
initialtimeofavailability.Ifnodurationparameterisgiven,the
serviceisassumedtobeavailableindefinitely.
Examples:
Retry-After:18000;duration=3600
Retry-After:120(I'minameeting)
20.34Route
TheRouteheaderfieldisusedtoforceroutingforarequestthrough
thelistedsetofproxies.ExamplesoftheuseoftheRouteheader
fieldareinSection16.12.1.
Example:
Route:,
20.35Server
TheServerheaderfieldcontainsinformationaboutthesoftwareused
bytheUAStohandletherequest.
Revealingthespecificsoftwareversionoftheservermightallowthe
servertobecomemorevulnerabletoattacksagainstsoftwarethatis
knowntocontainsecurityholes.ImplementersSHOULDmaketheServer
headerfieldaconfigurableoption.
Example:
Server:HomeServerv2
20.36Subject
TheSubjectheaderfieldprovidesasummaryorindicatesthenature
ofthecall,allowingcallfilteringwithouthavingtoparsethe
sessiondescription.Thesessiondescriptiondoesnothavetouse
thesamesubjectindicationastheinvitation.
ThecompactformoftheSubjectheaderfieldiss.
Rosenberg,et.al.StandardsTrack[Page177]
RFC3261SIP:SessionInitiationProtocolJune2002
Example:
Subject:Needmoreboxes
s:TechSupport
20.37Supported
TheSupportedheaderfieldenumeratesalltheextensionssupportedby
theUACorUAS.
TheSupportedheaderfieldcontainsalistofoptiontags,described
inSection19.2,thatareunderstoodbytheUACorUAS.AUA
complianttothisspecificationMUSTonlyincludeoptiontags
correspondingtostandards-trackRFCs.Ifempty,itmeansthatno
extensionsaresupported.
ThecompactformoftheSupportedheaderfieldisk.
Example:
Supported:100rel
20.38Timestamp
TheTimestampheaderfielddescribeswhentheUACsenttherequestto
theUAS.
SeeSection8.2.6fordetailsonhowtogeneratearesponsetoa
requestthatcontainstheheaderfield.Althoughthereisno
normativebehaviordefinedherethatmakesuseoftheheader,it
allowsforextensionsorSIPapplicationstoobtainRTTestimates.
Example:
Timestamp:54
20.39To
TheToheaderfieldspecifiesthelogicalrecipientoftherequest.
Theoptional"display-name"ismeanttoberenderedbyahuman-user
interface.The"tag"parameterservesasageneralmechanismfor
dialogidentification.
SeeSection19.3fordetailsofthe"tag"parameter.
Rosenberg,et.al.StandardsTrack[Page178]
RFC3261SIP:SessionInitiationProtocolJune2002
ComparisonofToheaderfieldsforequalityisidenticalto
comparisonofFromheaderfields.SeeSection20.10fortherules
forparsingadisplayname,URIandURIparameters,andheaderfield
parameters.
ThecompactformoftheToheaderfieldist.
ThefollowingareexamplesofvalidToheaderfields:
To:TheOperator;tag=287447
t:sip:[email protected]
20.40Unsupported
TheUnsupportedheaderfieldliststhefeaturesnotsupportedbythe
UAS.SeeSection20.32formotivation.
Example:
Unsupported:foo
20.41User-Agent
TheUser-AgentheaderfieldcontainsinformationabouttheUAC
originatingtherequest.Thesemanticsofthisheaderfieldare
definedin[H14.43].
Revealingthespecificsoftwareversionoftheuseragentmightallow
theuseragenttobecomemorevulnerabletoattacksagainstsoftware
thatisknowntocontainsecurityholes.ImplementersSHOULDmake
theUser-Agentheaderfieldaconfigurableoption.
Example:
User-Agent:SoftphoneBeta1.5
20.42Via
TheViaheaderfieldindicatesthepathtakenbytherequestsofar
andindicatesthepaththatshouldbefollowedinroutingresponses.
ThebranchIDparameterintheViaheaderfieldvaluesservesasa
transactionidentifier,andisusedbyproxiestodetectloops.
AViaheaderfieldvaluecontainsthetransportprotocolusedtosend
themessage,theclient'shostnameornetworkaddress,andpossibly
theportnumberatwhichitwishestoreceiveresponses.AVia
headerfieldvaluecanalsocontainparameterssuchas"maddr",
"ttl","received",and"branch",whosemeaningandusearedescribed
Rosenberg,et.al.StandardsTrack[Page179]
RFC3261SIP:SessionInitiationProtocolJune2002
inothersections.Forimplementationscomplianttothis
specification,thevalueofthebranchparameterMUSTstartwiththe
magiccookie"z9hG4bK",asdiscussedinSection8.1.1.7.
Transportprotocolsdefinedhereare"UDP","TCP","TLS",and"SCTP".
"TLS"meansTLSoverTCP.WhenarequestissenttoaSIPSURI,the
protocolstillindicates"SIP",andthetransportprotocolisTLS.
Via:SIP/2.0/UDPerlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via:SIP/2.0/UDP192.0.2.1:5060;received=192.0.2.207
;branch=z9hG4bK77asjd
ThecompactformoftheViaheaderfieldisv.
Inthisexample,themessageoriginatedfromamulti-homedhostwith
twoaddresses,192.0.2.1and192.0.2.207.Thesenderguessedwrong
astowhichnetworkinterfacewouldbeused.Erlang.bell-
telephone.comnoticedthemismatchandaddedaparametertothe
previoushop'sViaheaderfieldvalue,containingtheaddressthat
thepacketactuallycamefrom.
Thehostornetworkaddressandportnumberarenotrequiredto
followtheSIPURIsyntax.Specifically,LWSoneithersideofthe
":"or"/"isallowed,asshownhere:
Via:SIP/2.0/UDPfirst.example.com:4000;ttl=16
;maddr=224.2.0.1;branch=z9hG4bKa7c6a8dlze.1
Eventhoughthisspecificationmandatesthatthebranchparameterbe
presentinallrequests,theBNFfortheheaderfieldindicatesthat
itisoptional.ThisallowsinteroperationwithRFC2543elements,
whichdidnothavetoinsertthebranchparameter.
TwoViaheaderfieldsareequaliftheirsent-protocolandsent-by
fieldsareequal,bothhavethesamesetofparameters,andthe
valuesofallparametersareequal.
20.43Warning
TheWarningheaderfieldisusedtocarryadditionalinformation
aboutthestatusofaresponse.Warningheaderfieldvaluesaresent
withresponsesandcontainathree-digitwarningcode,hostname,and
warningtext.
The"warn-text"shouldbeinanaturallanguagethatismostlikely
tobeintelligibletothehumanuserreceivingtheresponse.This
decisioncanbebasedonanyavailableknowledge,suchasthe
locationoftheuser,theAccept-Languagefieldinarequest,orthe
Rosenberg,et.al.StandardsTrack[Page180]
RFC3261SIP:SessionInitiationProtocolJune2002
Content-Languagefieldinaresponse.Thedefaultlanguageisi-
default[21].
Thecurrently-defined"warn-code"sarelistedbelow,witha
recommendedwarn-textinEnglishandadescriptionoftheirmeaning.
Thesewarningsdescribefailuresinducedbythesessiondescription.
Thefirstdigitofwarningcodesbeginningwith"3"indicates
warningsspecifictoSIP.Warnings300through329arereservedfor
indicatingproblemswithkeywordsinthesessiondescription,330
through339arewarningsrelatedtobasicnetworkservicesrequested
inthesessiondescription,370through379arewarningsrelatedto
quantitativeQoSparametersrequestedinthesessiondescription,and
390through399aremiscellaneouswarningsthatdonotfallintoone
oftheabovecategories.
300Incompatiblenetworkprotocol:Oneormorenetworkprotocols
containedinthesessiondescriptionarenotavailable.
301Incompatiblenetworkaddressformats:Oneormorenetwork
addressformatscontainedinthesessiondescriptionarenot
available.
302Incompatibletransportprotocol:Oneormoretransport
protocolsdescribedinthesessiondescriptionarenot
available.
303Incompatiblebandwidthunits:Oneormorebandwidth
measurementunitscontainedinthesessiondescriptionwere
notunderstood.
304Mediatypenotavailable:Oneormoremediatypescontainedin
thesessiondescriptionarenotavailable.
305Incompatiblemediaformat:Oneormoremediaformatscontained
inthesessiondescriptionarenotavailable.
306Attributenotunderstood:Oneormoreofthemediaattributes
inthesessiondescriptionarenotsupported.
307Sessiondescriptionparameternotunderstood:Aparameter
otherthanthoselistedabovewasnotunderstood.
330Multicastnotavailable:Thesitewheretheuserislocated
doesnotsupportmulticast.
331Unicastnotavailable:Thesitewheretheuserislocateddoes
notsupportunicastcommunication(usuallyduetothepresence
ofafirewall).
Rosenberg,et.al.StandardsTrack[Page181]
RFC3261SIP:SessionInitiationProtocolJune2002
370Insufficientbandwidth:Thebandwidthspecifiedinthesession
descriptionordefinedbythemediaexceedsthatknowntobe
available.
399Miscellaneouswarning:Thewarningtextcanincludearbitrary
informationtobepresentedtoahumanuserorlogged.A
systemreceivingthiswarningMUSTNOTtakeanyautomated
action.
1xxand2xxhavebeentakenbyHTTP/1.1.
Additional"warn-code"scanbedefinedthroughIANA,asdefinedin
Section27.2.
Examples:
Warning:307isi.edu"Sessionparameter'foo'notunderstood"
Warning:301isi.edu"Incompatiblenetworkaddresstype'E.164'"
20.44WWW-Authenticate
AWWW-Authenticateheaderfieldvaluecontainsanauthentication
challenge.SeeSection22.2forfurtherdetailsonitsusage.
Example:
WWW-Authenticate:Digestrealm="atlanta.com",
domain="sip:boxesbybob.com",qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="",stale=FALSE,algorithm=MD5
21ResponseCodes
Theresponsecodesareconsistentwith,andextend,HTTP/1.1response
codes.NotallHTTP/1.1responsecodesareappropriate,andonly
thosethatareappropriatearegivenhere.OtherHTTP/1.1response
codesSHOULDNOTbeused.Also,SIPdefinesanewclass,6xx.
21.1Provisional1xx
Provisionalresponses,alsoknownasinformationalresponses,
indicatethattheservercontactedisperformingsomefurtheraction
anddoesnotyethaveadefinitiveresponse.Aserversendsa1xx
responseifitexpectstotakemorethan200mstoobtainafinal
response.Notethat1xxresponsesarenottransmittedreliably.
TheynevercausetheclienttosendanACK.Provisional(1xx)
responsesMAYcontainmessagebodies,includingsessiondescriptions.
Rosenberg,et.al.StandardsTrack[Page182]
RFC3261SIP:SessionInitiationProtocolJune2002
21.1.1100Trying
Thisresponseindicatesthattherequesthasbeenreceivedbythe
next-hopserverandthatsomeunspecifiedactionisbeingtakenon
behalfofthiscall(forexample,adatabaseisbeingconsulted).
Thisresponse,likeallotherprovisionalresponses,stops
retransmissionsofanINVITEbyaUAC.The100(Trying)responseis
differentfromotherprovisionalresponses,inthatitisnever
forwardedupstreambyastatefulproxy.
21.1.2180Ringing
TheUAreceivingtheINVITEistryingtoalerttheuser.This
responseMAYbeusedtoinitiatelocalringback.
21.1.3181CallIsBeingForwarded
AserverMAYusethisstatuscodetoindicatethatthecallisbeing
forwardedtoadifferentsetofdestinations.
21.1.4182Queued
Thecalledpartyistemporarilyunavailable,buttheserverhas
decidedtoqueuethecallratherthanrejectit.Whenthecallee
becomesavailable,itwillreturntheappropriatefinalstatus
response.ThereasonphraseMAYgivefurtherdetailsaboutthe
statusofthecall,forexample,"5callsqueued;expectedwaiting
timeis15minutes".TheserverMAYissueseveral182(Queued)
responsestoupdatethecalleraboutthestatusofthequeuedcall.
21.1.5183SessionProgress
The183(SessionProgress)responseisusedtoconveyinformation
abouttheprogressofthecallthatisnototherwiseclassified.The
Reason-Phrase,headerfields,ormessagebodyMAYbeusedtoconvey
moredetailsaboutthecallprogress.
21.2Successful2xx
Therequestwassuccessful.
21.2.1200OK
Therequesthassucceeded.Theinformationreturnedwiththe
responsedependsonthemethodusedintherequest.
Rosenberg,et.al.StandardsTrack[Page183]
RFC3261SIP:SessionInitiationProtocolJune2002
21.3Redirection3xx
3xxresponsesgiveinformationabouttheuser'snewlocation,or
aboutalternativeservicesthatmightbeabletosatisfythecall.
21.3.1300MultipleChoices
Theaddressintherequestresolvedtoseveralchoices,eachwithits
ownspecificlocation,andtheuser(orUA)canselectapreferred
communicationendpointandredirectitsrequesttothatlocation.
TheresponseMAYincludeamessagebodycontainingalistofresource
characteristicsandlocation(s)fromwhichtheuserorUAcanchoose
theonemostappropriate,ifallowedbytheAcceptrequestheader
field.However,noMIMEtypeshavebeendefinedforthismessage
body.
ThechoicesSHOULDalsobelistedasContactfields(Section20.10).
UnlikeHTTP,theSIPresponseMAYcontainseveralContactfieldsora
listofaddressesinaContactfield.UAsMAYusetheContactheader
fieldvalueforautomaticredirectionorMAYasktheusertoconfirm
achoice.However,thisspecificationdoesnotdefineanystandard
forsuchautomaticselection.
Thisstatusresponseisappropriateifthecalleecanbereached
atseveraldifferentlocationsandtheservercannotorprefers
nottoproxytherequest.
21.3.2301MovedPermanently
TheusercannolongerbefoundattheaddressintheRequest-URI,
andtherequestingclientSHOULDretryatthenewaddressgivenby
theContactheaderfield(Section20.10).TherequestorSHOULD
updateanylocaldirectories,addressbooks,anduserlocationcaches
withthisnewvalueandredirectfuturerequeststotheaddress(es)
listed.
21.3.3302MovedTemporarily
TherequestingclientSHOULDretrytherequestatthenewaddress(es)
givenbytheContactheaderfield(Section20.10).TheRequest-URI
ofthenewrequestusesthevalueoftheContactheaderfieldinthe
response.
Rosenberg,et.al.StandardsTrack[Page184]
RFC3261SIP:SessionInitiationProtocolJune2002
ThedurationofthevalidityoftheContactURIcanbeindicated
throughanExpires(Section20.19)headerfieldoranexpires
parameterintheContactheaderfield.BothproxiesandUAsMAY
cachethisURIforthedurationoftheexpirationtime.Ifthereis
noexplicitexpirationtime,theaddressisonlyvalidoncefor
recursing,andMUSTNOTbecachedforfuturetransactions.
IftheURIcachedfromtheContactheaderfieldfails,theRequest-
URIfromtheredirectedrequestMAYbetriedagainasingletime.
ThetemporaryURImayhavebecomeout-of-datesoonerthanthe
expirationtime,andanewtemporaryURImaybeavailable.
21.3.4305UseProxy
TherequestedresourceMUSTbeaccessedthroughtheproxygivenby
theContactfield.TheContactfieldgivestheURIoftheproxy.
Therecipientisexpectedtorepeatthissinglerequestviathe
proxy.305(UseProxy)responsesMUSTonlybegeneratedbyUASs.
21.3.5380AlternativeService
Thecallwasnotsuccessful,butalternativeservicesarepossible.
Thealternativeservicesaredescribedinthemessagebodyofthe
response.Formatsforsuchbodiesarenotdefinedhere,andmaybe
thesubjectoffuturestandardization.
21.4RequestFailure4xx
4xxresponsesaredefinitefailureresponsesfromaparticular
server.TheclientSHOULDNOTretrythesamerequestwithout
modification(forexample,addingappropriateauthorization).
However,thesamerequesttoadifferentservermightbesuccessful.
21.4.1400BadRequest
Therequestcouldnotbeunderstoodduetomalformedsyntax.The
Reason-PhraseSHOULDidentifythesyntaxprobleminmoredetail,for
example,"MissingCall-IDheaderfield".
21.4.2401Unauthorized
Therequestrequiresuserauthentication.Thisresponseisissuedby
UASsandregistrars,while407(ProxyAuthenticationRequired)is
usedbyproxyservers.
Rosenberg,et.al.StandardsTrack[Page185]
RFC3261SIP:SessionInitiationProtocolJune2002
21.4.3402PaymentRequired
Reservedforfutureuse.
21.4.4403Forbidden
Theserverunderstoodtherequest,butisrefusingtofulfillit.
Authorizationwillnothelp,andtherequestSHOULDNOTberepeated.
21.4.5404NotFound
Theserverhasdefinitiveinformationthattheuserdoesnotexistat
thedomainspecifiedintheRequest-URI.Thisstatusisalso
returnedifthedomainintheRequest-URIdoesnotmatchanyofthe
domainshandledbytherecipientoftherequest.
21.4.6405MethodNotAllowed
ThemethodspecifiedintheRequest-Lineisunderstood,butnot
allowedfortheaddressidentifiedbytheRequest-URI.
TheresponseMUSTincludeanAllowheaderfieldcontainingalistof
validmethodsfortheindicatedaddress.
21.4.7406NotAcceptable
Theresourceidentifiedbytherequestisonlycapableofgenerating
responseentitiesthathavecontentcharacteristicsnotacceptable
accordingtotheAcceptheaderfieldsentintherequest.
21.4.8407ProxyAuthenticationRequired
Thiscodeissimilarto401(Unauthorized),butindicatesthatthe
clientMUSTfirstauthenticateitselfwiththeproxy.SIPaccess
authenticationisexplainedinSections26and22.3.
Thisstatuscodecanbeusedforapplicationswhereaccesstothe
communicationchannel(forexample,atelephonygateway)ratherthan
thecalleerequiresauthentication.
21.4.9408RequestTimeout
Theservercouldnotproducearesponsewithinasuitableamountof
time,forexample,ifitcouldnotdeterminethelocationoftheuser
intime.TheclientMAYrepeattherequestwithoutmodificationsat
anylatertime.
Rosenberg,et.al.StandardsTrack[Page186]
RFC3261SIP:SessionInitiationProtocolJune2002
21.4.10410Gone
Therequestedresourceisnolongeravailableattheserverandno
forwardingaddressisknown.Thisconditionisexpectedtobe
consideredpermanent.Iftheserverdoesnotknow,orhasno
facilitytodetermine,whetherornottheconditionispermanent,the
statuscode404(NotFound)SHOULDbeusedinstead.
21.4.11413RequestEntityTooLarge
Theserverisrefusingtoprocessarequestbecausetherequest
entity-bodyislargerthantheserveriswillingorabletoprocess.
TheserverMAYclosetheconnectiontopreventtheclientfrom
continuingtherequest.
Iftheconditionistemporary,theserverSHOULDincludeaRetry-
Afterheaderfieldtoindicatethatitistemporaryandafterwhat
timetheclientMAYtryagain.
21.4.12414Request-URITooLong
TheserverisrefusingtoservicetherequestbecausetheRequest-URI
islongerthantheserveriswillingtointerpret.
21.4.13415UnsupportedMediaType
Theserverisrefusingtoservicetherequestbecausethemessage
bodyoftherequestisinaformatnotsupportedbytheserverfor
therequestedmethod.TheserverMUSTreturnalistofacceptable
formatsusingtheAccept,Accept-Encoding,orAccept-Languageheader
field,dependingonthespecificproblemwiththecontent.UAC
processingofthisresponseisdescribedinSection8.1.3.5.
21.4.14416UnsupportedURIScheme
TheservercannotprocesstherequestbecausetheschemeoftheURI
intheRequest-URIisunknowntotheserver.Clientprocessingof
thisresponseisdescribedinSection8.1.3.5.
21.4.15420BadExtension
Theserverdidnotunderstandtheprotocolextensionspecifiedina
Proxy-Require(Section20.29)orRequire(Section20.32)header
field.TheserverMUSTincludealistoftheunsupportedextensions
inanUnsupportedheaderfieldintheresponse.UACprocessingof
thisresponseisdescribedinSection8.1.3.5.
Rosenberg,et.al.StandardsTrack[Page187]
RFC3261SIP:SessionInitiationProtocolJune2002
21.4.16421ExtensionRequired
TheUASneedsaparticularextensiontoprocesstherequest,butthis
extensionisnotlistedinaSupportedheaderfieldintherequest.
ResponseswiththisstatuscodeMUSTcontainaRequireheaderfield
listingtherequiredextensions.
AUASSHOULDNOTusethisresponseunlessittrulycannotprovideany
usefulservicetotheclient.Instead,ifadesirableextensionis
notlistedintheSupportedheaderfield,serversSHOULDprocessthe
requestusingbaselineSIPcapabilitiesandanyextensionssupported
bytheclient.
21.4.17423IntervalTooBrief
Theserverisrejectingtherequestbecausetheexpirationtimeof
theresourcerefreshedbytherequestistooshort.Thisresponse
canbeusedbyaregistrartorejectaregistrationwhoseContact
headerfieldexpirationtimewastoosmall.Theuseofthisresponse
andtherelatedMin-ExpiresheaderfieldaredescribedinSections
10.2.8,10.3,and20.23.
21.4.18480TemporarilyUnavailable
Thecallee'sendsystemwascontactedsuccessfullybutthecalleeis
currentlyunavailable(forexample,isnotloggedin,loggedinbut
inastatethatprecludescommunicationwiththecallee,orhas
activatedthe"donotdisturb"feature).TheresponseMAYindicatea
bettertimetocallintheRetry-Afterheaderfield.Theusercould
alsobeavailableelsewhere(unbeknownsttothisserver).Thereason
phraseSHOULDindicateamoreprecisecauseastowhythecalleeis
unavailable.ThisvalueSHOULDbesettablebytheUA.Status486
(BusyHere)MAYbeusedtomorepreciselyindicateaparticular
reasonforthecallfailure.
Thisstatusisalsoreturnedbyaredirectorproxyserverthat
recognizestheuseridentifiedbytheRequest-URI,butdoesnot
currentlyhaveavalidforwardinglocationforthatuser.
21.4.19481Call/TransactionDoesNotExist
ThisstatusindicatesthattheUASreceivedarequestthatdoesnot
matchanyexistingdialogortransaction.
21.4.20482LoopDetected
Theserverhasdetectedaloop(Section16.3Item4).
Rosenberg,et.al.StandardsTrack[Page188]
RFC3261SIP:SessionInitiationProtocolJune2002
21.4.21483TooManyHops
TheserverreceivedarequestthatcontainsaMax-Forwards(Section
20.22)headerfieldwiththevaluezero.
21.4.22484AddressIncomplete
TheserverreceivedarequestwithaRequest-URIthatwasincomplete.
AdditionalinformationSHOULDbeprovidedinthereasonphrase.
Thisstatuscodeallowsoverlappeddialing.Withoverlapped
dialing,theclientdoesnotknowthelengthofthedialing
string.Itsendsstringsofincreasinglengths,promptingthe
userformoreinput,untilitnolongerreceivesa484(Address
Incomplete)statusresponse.
21.4.23485Ambiguous
TheRequest-URIwasambiguous.TheresponseMAYcontainalistingof
possibleunambiguousaddressesinContactheaderfields.Revealing
alternativescaninfringeonprivacyoftheuserortheorganization.
ItMUSTbepossibletoconfigureaservertorespondwithstatus404
(NotFound)ortosuppressthelistingofpossiblechoicesfor
ambiguousRequest-URIs.
ExampleresponsetoarequestwiththeRequest-URI
sip:[email protected]:
SIP/2.0485Ambiguous
Contact:CarolLee
Contact:PingLee
Contact:LeeM.Foote
Someemailandvoicemailsystemsprovidethisfunctionality.A
statuscodeseparatefrom3xxisusedsincethesemanticsare
different:for300,itisassumedthatthesamepersonorservice
willbereachedbythechoicesprovided.Whileanautomated
choiceorsequentialsearchmakessensefora3xxresponse,user
interventionisrequiredfora485(Ambiguous)response.
21.4.24486BusyHere
Thecallee'sendsystemwascontactedsuccessfully,butthecalleeis
currentlynotwillingorabletotakeadditionalcallsatthisend
system.TheresponseMAYindicateabettertimetocallinthe
Retry-Afterheaderfield.Theusercouldalsobeavailable
Rosenberg,et.al.StandardsTrack[Page189]
RFC3261SIP:SessionInitiationProtocolJune2002
elsewhere,suchasthroughavoicemailservice.Status600(Busy
Everywhere)SHOULDbeusediftheclientknowsthatnootherend
systemwillbeabletoacceptthiscall.
21.4.25487RequestTerminated
TherequestwasterminatedbyaBYEorCANCELrequest.Thisresponse
isneverreturnedforaCANCELrequestitself.
21.4.26488NotAcceptableHere
Theresponsehasthesamemeaningas606(NotAcceptable),butonly
appliestothespecificresourceaddressedbytheRequest-URIandthe
requestmaysucceedelsewhere.
AmessagebodycontainingadescriptionofmediacapabilitiesMAYbe
presentintheresponse,whichisformattedaccordingtotheAccept
headerfieldintheINVITE(orapplication/sdpifnotpresent),the
sameasamessagebodyina200(OK)responsetoanOPTIONSrequest.
21.4.27491RequestPending
TherequestwasreceivedbyaUASthathadapendingrequestwithin
thesamedialog.Section14.2describeshowsuch"glare"situations
areresolved.
21.4.28493Undecipherable
TherequestwasreceivedbyaUASthatcontainedanencryptedMIME
bodyforwhichtherecipientdoesnotpossessorwillnotprovidean
appropriatedecryptionkey.ThisresponseMAYhaveasinglebody
containinganappropriatepublickeythatshouldbeusedtoencrypt
MIMEbodiessenttothisUA.Detailsoftheusageofthisresponse
codecanbefoundinSection23.2.
21.5ServerFailure5xx
5xxresponsesarefailureresponsesgivenwhenaserveritselfhas
erred.
21.5.1500ServerInternalError
Theserverencounteredanunexpectedconditionthatpreventeditfrom
fulfillingtherequest.TheclientMAYdisplaythespecificerror
conditionandMAYretrytherequestafterseveralseconds.
Iftheconditionistemporary,theserverMAYindicatewhenthe
clientmayretrytherequestusingtheRetry-Afterheaderfield.
Rosenberg,et.al.StandardsTrack[Page190]
RFC3261SIP:SessionInitiationProtocolJune2002
21.5.2501NotImplemented
Theserverdoesnotsupportthefunctionalityrequiredtofulfillthe
request.ThisistheappropriateresponsewhenaUASdoesnot
recognizetherequestmethodandisnotcapableofsupportingitfor
anyuser.(Proxiesforwardallrequestsregardlessofmethod.)
Notethata405(MethodNotAllowed)issentwhentheserver
recognizestherequestmethod,butthatmethodisnotallowedor
supported.
21.5.3502BadGateway
Theserver,whileactingasagatewayorproxy,receivedaninvalid
responsefromthedownstreamserveritaccessedinattemptingto
fulfilltherequest.
21.5.4503ServiceUnavailable
Theserveristemporarilyunabletoprocesstherequestduetoa
temporaryoverloadingormaintenanceoftheserver.TheserverMAY
indicatewhentheclientshouldretrytherequestinaRetry-After
headerfield.IfnoRetry-Afterisgiven,theclientMUSTactasif
ithadreceiveda500(ServerInternalError)response.
Aclient(proxyorUAC)receivinga503(ServiceUnavailable)SHOULD
attempttoforwardtherequesttoanalternateserver.ItSHOULDNOT
forwardanyotherrequeststothatserverforthedurationspecified
intheRetry-Afterheaderfield,ifpresent.
ServersMAYrefusetheconnectionordroptherequestinsteadof
respondingwith503(ServiceUnavailable).
21.5.5504ServerTime-out
Theserverdidnotreceiveatimelyresponsefromanexternalserver
itaccessedinattemptingtoprocesstherequest.408(Request
Timeout)shouldbeusedinsteadiftherewasnoresponsewithinthe
periodspecifiedintheExpiresheaderfieldfromtheupstream
server.
21.5.6505VersionNotSupported
Theserverdoesnotsupport,orrefusestosupport,theSIPprotocol
versionthatwasusedintherequest.Theserverisindicatingthat
itisunableorunwillingtocompletetherequestusingthesame
majorversionastheclient,otherthanwiththiserrormessage.
Rosenberg,et.al.StandardsTrack[Page191]
RFC3261SIP:SessionInitiationProtocolJune2002
21.5.7513MessageTooLarge
Theserverwasunabletoprocesstherequestsincethemessagelength
exceededitscapabilities.
21.6GlobalFailures6xx
6xxresponsesindicatethataserverhasdefinitiveinformationabout
aparticularuser,notjusttheparticularinstanceindicatedinthe
Request-URI.
21.6.1600BusyEverywhere
Thecallee'sendsystemwascontactedsuccessfullybutthecalleeis
busyanddoesnotwishtotakethecallatthistime.Theresponse
MAYindicateabettertimetocallintheRetry-Afterheaderfield.
Ifthecalleedoesnotwishtorevealthereasonfordecliningthe
call,thecalleeusesstatuscode603(Decline)instead.Thisstatus
responseisreturnedonlyiftheclientknowsthatnootherendpoint
(suchasavoicemailsystem)willanswertherequest.Otherwise,
486(BusyHere)shouldbereturned.
21.6.2603Decline
Thecallee'smachinewassuccessfullycontactedbuttheuser
explicitlydoesnotwishtoorcannotparticipate.TheresponseMAY
indicateabettertimetocallintheRetry-Afterheaderfield.This
statusresponseisreturnedonlyiftheclientknowsthatnoother
endpointwillanswertherequest.
21.6.3604DoesNotExistAnywhere
Theserverhasauthoritativeinformationthattheuserindicatedin
theRequest-URIdoesnotexistanywhere.
21.6.4606NotAcceptable
Theuser'sagentwascontactedsuccessfullybutsomeaspectsofthe
sessiondescriptionsuchastherequestedmedia,bandwidth,or
addressingstylewerenotacceptable.
A606(NotAcceptable)responsemeansthattheuserwishesto
communicate,butcannotadequatelysupportthesessiondescribed.
The606(NotAcceptable)responseMAYcontainalistofreasonsina
Warningheaderfielddescribingwhythesessiondescribedcannotbe
supported.WarningreasoncodesarelistedinSection20.43.
Rosenberg,et.al.StandardsTrack[Page192]
RFC3261SIP:SessionInitiationProtocolJune2002
AmessagebodycontainingadescriptionofmediacapabilitiesMAYbe
presentintheresponse,whichisformattedaccordingtotheAccept
headerfieldintheINVITE(orapplication/sdpifnotpresent),the
sameasamessagebodyina200(OK)responsetoanOPTIONSrequest.
Itishopedthatnegotiationwillnotfrequentlybeneeded,andwhen
anewuserisbeinginvitedtojoinanalreadyexistingconference,
negotiationmaynotbepossible.Itisuptotheinvitation
initiatortodecidewhetherornottoactona606(NotAcceptable)
response.
Thisstatusresponseisreturnedonlyiftheclientknowsthatno
otherendpointwillanswertherequest.
22UsageofHTTPAuthentication
SIPprovidesastateless,challenge-basedmechanismfor
authenticationthatisbasedonauthenticationinHTTP.Anytime
thataproxyserverorUAreceivesarequest(withtheexceptions
giveninSection22.1),itMAYchallengetheinitiatoroftherequest
toprovideassuranceofitsidentity.Oncetheoriginatorhasbeen
identified,therecipientoftherequestSHOULDascertainwhetheror
notthisuserisauthorizedtomaketherequestinquestion.No
authorizationsystemsarerecommendedordiscussedinthisdocument.
The"Digest"authenticationmechanismdescribedinthissection
providesmessageauthenticationandreplayprotectiononly,without
messageintegrityorconfidentiality.Protectivemeasuresaboveand
beyondthoseprovidedbyDigestneedtobetakentopreventactive
attackersfrommodifyingSIPrequestsandresponses.
Notethatduetoitsweaksecurity,theusageof"Basic"
authenticationhasbeendeprecated.ServersMUSTNOTaccept
credentialsusingthe"Basic"authorizationscheme,andserversalso
MUSTNOTchallengewith"Basic".ThisisachangefromRFC2543.
22.1Framework
TheframeworkforSIPauthenticationcloselyparallelsthatofHTTP
(RFC2617[17]).Inparticular,theBNFforauth-scheme,auth-param,
challenge,realm,realm-value,andcredentialsisidentical(although
theusageof"Basic"asaschemeisnotpermitted).InSIP,aUAS
usesthe401(Unauthorized)responsetochallengetheidentityofa
UAC.Additionally,registrarsandredirectserversMAYmakeuseof
401(Unauthorized)responsesforauthentication,butproxiesMUST
NOT,andinsteadMAYusethe407(ProxyAuthenticationRequired)
Rosenberg,et.al.StandardsTrack[Page193]
RFC3261SIP:SessionInitiationProtocolJune2002
response.TherequirementsforinclusionoftheProxy-Authenticate,
Proxy-Authorization,WWW-Authenticate,andAuthorizationinthe
variousmessagesareidenticaltothosedescribedinRFC2617[17].
SinceSIPdoesnothavetheconceptofacanonicalrootURL,the
notionofprotectionspacesisinterpreteddifferentlyinSIP.The
realmstringalonedefinestheprotectiondomain.Thisisachange
fromRFC2543,inwhichtheRequest-URIandtherealmtogether
definedtheprotectiondomain.
Thispreviousdefinitionofprotectiondomaincausedsomeamount
ofconfusionsincetheRequest-URIsentbytheUACandthe
Request-URIreceivedbythechallengingservermightbedifferent,
andindeedthefinalformoftheRequest-URImightnotbeknownto
theUAC.Also,thepreviousdefinitiondependedonthepresence
ofaSIPURIintheRequest-URIandseemedtoruleoutalternative
URIschemes(forexample,thetelURL).
Operatorsofuseragentsorproxyserversthatwillauthenticate
receivedrequestsMUSTadheretothefollowingguidelinesfor
creationofarealmstringfortheirserver:
oRealmstringsMUSTbegloballyunique.ItisRECOMMENDEDthat
arealmstringcontainahostnameordomainname,followingthe
recommendationinSection 3.2.1ofRFC2617[17].
oRealmstringsSHOULDpresentahuman-readableidentifierthat
canberenderedtoauser.
Forexample:
INVITEsip:[email protected]/2.0
Authorization:Digestrealm="biloxi.com",<...>
Generally,SIPauthenticationismeaningfulforaspecificrealm,a
protectiondomain.Thus,forDigestauthentication,eachsuch
protectiondomainhasitsownsetofusernamesandpasswords.Ifa
serverdoesnotrequireauthenticationforaparticularrequest,it
MAYacceptadefaultusername,"anonymous",whichhasnopassword
(passwordof"").Similarly,UACsrepresentingmanyusers,suchas
PSTNgateways,MAYhavetheirowndevice-specificusernameand
password,ratherthanaccountsforparticularusers,fortheirrealm.
WhileaservercanlegitimatelychallengemostSIPrequests,there
aretworequestsdefinedbythisdocumentthatrequirespecial
handlingforauthentication:ACKandCANCEL.
Rosenberg,et.al.StandardsTrack[Page194]
RFC3261SIP:SessionInitiationProtocolJune2002
Underanauthenticationschemethatusesresponsestocarryvalues
usedtocomputenonces(suchasDigest),someproblemscomeupfor
anyrequeststhattakenoresponse,includingACK.Forthisreason,
anycredentialsintheINVITEthatwereacceptedbyaserverMUSTbe
acceptedbythatserverfortheACK.UACscreatinganACKmessage
willduplicatealloftheAuthorizationandProxy-Authorization
headerfieldvaluesthatappearedintheINVITEtowhichtheACK
corresponds.ServersMUSTNOTattempttochallengeanACK.
AlthoughtheCANCELmethoddoestakearesponse(a2xx),serversMUST
NOTattempttochallengeCANCELrequestssincetheserequestscannot
beresubmitted.Generally,aCANCELrequestSHOULDbeacceptedbya
serverifitcomesfromthesamehopthatsenttherequestbeing
canceled(providedthatsomesortoftransportornetworklayer
securityassociation,asdescribedinSection26.2.1,isinplace).
WhenaUACreceivesachallenge,itSHOULDrendertotheuserthe
contentsofthe"realm"parameterinthechallenge(whichappearsin
eitheraWWW-AuthenticateheaderfieldorProxy-Authenticateheader
field)iftheUACdevicedoesnotalreadyknowofacredentialfor
therealminquestion.Aserviceproviderthatpre-configuresUAs
withcredentialsforitsrealmshouldbeawarethatuserswillnot
havetheopportunitytopresenttheirowncredentialsforthisrealm
whenchallengedatapre-configureddevice.
Finally,notethatevenifaUACcanlocatecredentialsthatare
associatedwiththeproperrealm,thepotentialexiststhatthese
credentialsmaynolongerbevalidorthatthechallengingserver
willnotacceptthesecredentialsforwhateverreason(especially
when"anonymous"withnopasswordissubmitted).Inthisinstancea
servermayrepeatitschallenge,oritmayrespondwitha403
Forbidden.AUACMUSTNOTre-attemptrequestswiththecredentials
thathavejustbeenrejected(thoughtherequestmayberetriedif
thenoncewasstale).
22.2User-to-UserAuthentication
WhenaUASreceivesarequestfromaUAC,theUASMAYauthenticate
theoriginatorbeforetherequestisprocessed.Ifnocredentials
(intheAuthorizationheaderfield)areprovidedintherequest,the
UAScanchallengetheoriginatortoprovidecredentialsbyrejecting
therequestwitha401(Unauthorized)statuscode.
TheWWW-Authenticateresponse-headerfieldMUSTbeincludedin401
(Unauthorized)responsemessages.Thefieldvalueconsistsofat
leastonechallengethatindicatestheauthenticationscheme(s)and
parametersapplicabletotherealm.
Rosenberg,et.al.StandardsTrack[Page195]
RFC3261SIP:SessionInitiationProtocolJune2002
AnexampleoftheWWW-Authenticateheaderfieldina401challenge
is:
WWW-Authenticate:Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
WhentheoriginatingUACreceivesthe401(Unauthorized),itSHOULD,
ifitisable,re-originatetherequestwiththepropercredentials.
TheUACmayrequireinputfromtheoriginatinguserbefore
proceeding.Onceauthenticationcredentialshavebeensupplied
(eitherdirectlybytheuser,ordiscoveredinaninternalkeyring),
UAsSHOULDcachethecredentialsforagivenvalueoftheToheader
fieldand"realm"andattempttore-usethesevaluesonthenext
requestforthatdestination.UAsMAYcachecredentialsinanyway
theywouldlike.
Ifnocredentialsforarealmcanbelocated,UACsMAYattemptto
retrytherequestwithausernameof"anonymous"andnopassword(a
passwordof"").
Oncecredentialshavebeenlocated,anyUAthatwishesto
authenticateitselfwithaUASorregistrar--usually,butnot
necessarily,afterreceivinga401(Unauthorized)response--MAYdo
sobyincludinganAuthorizationheaderfieldwiththerequest.The
Authorizationfieldvalueconsistsofcredentialscontainingthe
authenticationinformationoftheUAfortherealmoftheresource
beingrequestedaswellasparametersrequiredinsupportof
authenticationandreplayprotection.
AnexampleoftheAuthorizationheaderfieldis:
Authorization:Digestusername="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:[email protected]",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
WhenaUACresubmitsarequestwithitscredentialsafterreceivinga
401(Unauthorized)or407(ProxyAuthenticationRequired)response,
itMUSTincrementtheCSeqheaderfieldvalueasitwouldnormally
whensendinganupdatedrequest.
Rosenberg,et.al.StandardsTrack[Page196]
RFC3261SIP:SessionInitiationProtocolJune2002
22.3Proxy-to-UserAuthentication
Similarly,whenaUACsendsarequesttoaproxyserver,theproxy
serverMAYauthenticatetheoriginatorbeforetherequestis
processed.Ifnocredentials(intheProxy-Authorizationheader
field)areprovidedintherequest,theproxycanchallengethe
originatortoprovidecredentialsbyrejectingtherequestwitha407
(ProxyAuthenticationRequired)statuscode.TheproxyMUSTpopulate
the407(ProxyAuthenticationRequired)messagewithaProxy-
Authenticateheaderfieldvalueapplicabletotheproxyforthe
requestedresource.
TheuseofProxy-AuthenticateandProxy-Authorizationparallelthat
describedin[17],withonedifference.ProxiesMUSTNOTaddvalues
totheProxy-Authorizationheaderfield.All407(Proxy
AuthenticationRequired)responsesMUSTbeforwardedupstreamtoward
theUACfollowingtheproceduresforanyotherresponse.Itisthe
UAC'sresponsibilitytoaddtheProxy-Authorizationheaderfield
valuecontainingcredentialsfortherealmoftheproxythathas
askedforauthentication.
IfaproxyweretoresubmitarequestaddingaProxy-Authorization
headerfieldvalue,itwouldneedtoincrementtheCSeqinthenew
request.However,thiswouldcausetheUACthatsubmittedthe
originalrequesttodiscardaresponsefromtheUAS,astheCSeq
valuewouldbedifferent.
WhentheoriginatingUACreceivesthe407(ProxyAuthentication
Required)itSHOULD,ifitisable,re-originatetherequestwiththe
propercredentials.Itshouldfollowthesameproceduresforthe
displayofthe"realm"parameterthataregivenaboveforresponding
to401.
Ifnocredentialsforarealmcanbelocated,UACsMAYattemptto
retrytherequestwithausernameof"anonymous"andnopassword(a
passwordof"").
TheUACSHOULDalsocachethecredentialsusedinthere-originated
request.
ThefollowingruleisRECOMMENDEDforproxycredentialcaching:
IfaUAreceivesaProxy-Authenticateheaderfieldvalueina401/407
responsetoarequestwithaparticularCall-ID,itshould
incorporatecredentialsforthatrealminallsubsequentrequests
thatcontainthesameCall-ID.ThesecredentialsMUSTNOTbecached
acrossdialogs;however,ifaUAisconfiguredwiththerealmofits
localoutboundproxy,whenoneexists,thentheUAMAYcache
Rosenberg,et.al.StandardsTrack[Page197]
RFC3261SIP:SessionInitiationProtocolJune2002
credentialsforthatrealmacrossdialogs.Notethatthisdoesmean
afuturerequestinadialogcouldcontaincredentialsthatarenot
neededbyanyproxyalongtheRouteheaderpath.
AnyUAthatwishestoauthenticateitselftoaproxyserver--
usually,butnotnecessarily,afterreceivinga407(Proxy
AuthenticationRequired)response--MAYdosobyincludingaProxy-
Authorizationheaderfieldvaluewiththerequest.TheProxy-
Authorizationrequest-headerfieldallowstheclienttoidentify
itself(oritsuser)toaproxythatrequiresauthentication.The
Proxy-Authorizationheaderfieldvalueconsistsofcredentials
containingtheauthenticationinformationoftheUAfortheproxy
and/orrealmoftheresourcebeingrequested.
AProxy-Authorizationheaderfieldvalueappliesonlytotheproxy
whoserealmisidentifiedinthe"realm"parameter(thisproxymay
previouslyhavedemandedauthenticationusingtheProxy-Authenticate
field).Whenmultipleproxiesareusedinachain,aProxy-
AuthorizationheaderfieldvalueMUSTNOTbeconsumedbyanyproxy
whoserealmdoesnotmatchthe"realm"parameterspecifiedinthat
value.
Notethatifanauthenticationschemethatdoesnotsupportrealmsis
usedintheProxy-Authorizationheaderfield,aproxyserverMUST
attempttoparseallProxy-Authorizationheaderfieldvaluesto
determinewhetheroneofthemhaswhattheproxyserverconsidersto
bevalidcredentials.Becausethisispotentiallyverytime-
consuminginlargenetworks,proxyserversSHOULDusean
authenticationschemethatsupportsrealmsintheProxy-Authorization
headerfield.
Ifarequestisforked(asdescribedinSection16.7),variousproxy
serversand/orUAsmaywishtochallengetheUAC.Inthiscase,the
forkingproxyserverisresponsibleforaggregatingthesechallenges
intoasingleresponse.EachWWW-AuthenticateandProxy-Authenticate
valuereceivedinresponsestotheforkedrequestMUSTbeplacedinto
thesingleresponsethatissentbytheforkingproxytotheUA;the
orderingoftheseheaderfieldvaluesisnotsignificant.
Whenaproxyserverissuesachallengeinresponsetoarequest,
itwillnotproxytherequestuntiltheUAChasretriedthe
requestwithvalidcredentials.Aforkingproxymayforwarda
requestsimultaneouslytomultipleproxyserversthatrequire
authentication,eachofwhichinturnwillnotforwardtherequest
untiltheoriginatingUAChasauthenticateditselfintheir
respectiverealm.IftheUACdoesnotprovidecredentialsfor
Rosenberg,et.al.StandardsTrack[Page198]
RFC3261SIP:SessionInitiationProtocolJune2002
eachchallenge,theproxyserversthatissuedthechallengeswill
notforwardrequeststotheUAwherethedestinationusermightbe
located,andtherefore,thevirtuesofforkingarelargelylost.
Whenresubmittingitsrequestinresponsetoa401(Unauthorized)or
407(ProxyAuthenticationRequired)thatcontainsmultiple
challenges,aUACMAYincludeanAuthorizationvalueforeachWWW-
AuthenticatevalueandaProxy-AuthorizationvalueforeachProxy-
AuthenticatevalueforwhichtheUACwishestosupplyacredential.
Asnotedabove,multiplecredentialsinarequestSHOULDbe
differentiatedbythe"realm"parameter.
Itispossibleformultiplechallengesassociatedwiththesamerealm
toappearinthesame401(Unauthorized)or407(ProxyAuthentication
Required).Thiscanoccur,forexample,whenmultipleproxieswithin
thesameadministrativedomain,whichuseacommonrealm,arereached
byaforkingrequest.Whenitretriesarequest,aUACMAYtherefore
supplymultiplecredentialsinAuthorizationorProxy-Authorization
headerfieldswiththesame"realm"parametervalue.Thesame
credentialsSHOULDbeusedforthesamerealm.
22.4TheDigestAuthenticationScheme
Thissectiondescribesthemodificationsandclarificationsrequired
toapplytheHTTPDigestauthenticationschemetoSIP.TheSIP
schemeusageisalmostcompletelyidenticaltothatforHTTP[17].
SinceRFC2543isbasedonHTTPDigestasdefinedinRFC2069[39],
SIPserverssupportingRFC2617MUSTensuretheyarebackwards
compatiblewithRFC2069.Proceduresforthisbackwards
compatibilityarespecifiedinRFC2617.Note,however,thatSIP
serversMUSTNOTacceptorrequestBasicauthentication.
TherulesforDigestauthenticationfollowthosedefinedin[17],
with"HTTP/1.1"replacedby"SIP/2.0"inadditiontothefollowing
differences:
1.TheURIincludedinthechallengehasthefollowingBNF:
URI=SIP-URI/SIPS-URI
2.TheBNFinRFC2617hasanerrorinthatthe'uri'parameter
oftheAuthorizationheaderfieldforHTTPDigest
Rosenberg,et.al.StandardsTrack[Page199]
RFC3261SIP:SessionInitiationProtocolJune2002
authenticationisnotenclosedinquotationmarks.(The
exampleinSection 3.5ofRFC2617iscorrect.)ForSIP,the
'uri'MUSTbeenclosedinquotationmarks.
3.TheBNFfordigest-uri-valueis:
digest-uri-value=Request-URI;asdefinedinSection25
4.TheexampleprocedureforchoosinganoncebasedonEtagdoes
notworkforSIP.
5.ThetextinRFC2617[17]regardingcacheoperationdoesnot
applytoSIP.
6.RFC2617[17]requiresthataservercheckthattheURIinthe
requestlineandtheURIincludedintheAuthorizationheader
fieldpointtothesameresource.InaSIPcontext,thesetwo
URIsmayrefertodifferentusers,duetoforwardingatsome
proxy.Therefore,inSIP,aserverMAYcheckthatthe
Request-URIintheAuthorizationheaderfieldvalue
correspondstoauserforwhomtheserveriswillingtoaccept
forwardedordirectrequests,butitisnotnecessarilya
failureifthetwofieldsarenotequivalent.
7.AsaclarificationtothecalculationoftheA2valuefor
messageintegrityassuranceintheDigestauthentication
scheme,implementersshouldassume,whentheentity-bodyis
empty(thatis,whenSIPmessageshavenobody)thatthehash
oftheentity-bodyresolvestotheMD5hashofanempty
string,or:
H(entity-body)=MD5("")=
"d41d8cd98f00b204e9800998ecf8427e"
8.RFC2617notesthatacnoncevalueMUSTNOTbesentinan
Authorization(andbyextensionProxy-Authorization)header
fieldifnoqopdirectivehasbeensent.Therefore,any
algorithmsthathaveadependencyonthecnonce(including
"MD5-Sess")requirethattheqopdirectivebesent.Useof
the"qop"parameterisoptionalinRFC2617forthepurposes
ofbackwardscompatibilitywithRFC2069;sinceRFC2543was
basedonRFC2069,the"qop"parametermustunfortunately
remainoptionalforclientsandserverstoreceive.However,
serversMUSTalwayssenda"qop"parameterinWWW-Authenticate
andProxy-Authenticateheaderfieldvalues.Ifaclient
receivesa"qop"parameterinachallengeheaderfield,it
MUSTsendthe"qop"parameterinanyresultingauthorization
headerfield.
Rosenberg,et.al.StandardsTrack[Page200]
RFC3261SIP:SessionInitiationProtocolJune2002
RFC2543didnotallowusageoftheAuthentication-Infoheaderfield
(iteffectivelyusedRFC2069).However,wenowallowusageofthis
headerfield,sinceitprovidesintegritychecksoverthebodiesand
providesmutualauthentication.RFC2617[17]definesmechanismsfor
backwardscompatibilityusingtheqopattributeintherequest.
ThesemechanismsMUSTbeusedbyaservertodetermineiftheclient
supportsthenewmechanismsinRFC2617thatwerenotspecifiedin
RFC2069.
23S/MIME
SIPmessagescarryMIMEbodiesandtheMIMEstandardincludes
mechanismsforsecuringMIMEcontentstoensurebothintegrityand
confidentiality(includingthe'multipart/signed'and
'application/pkcs7-mime'MIMEtypes,seeRFC1847[22],RFC2630[23]
andRFC2633[24]).Implementersshouldnote,however,thatthere
mayberarenetworkintermediaries(nottypicalproxyservers)that
relyonviewingormodifyingthebodiesofSIPmessages(especially
SDP),andthatsecureMIMEmaypreventthesesortsofintermediaries
fromfunctioning.
Thisappliesparticularlytocertaintypesoffirewalls.
ThePGPmechanismforencryptingtheheaderfieldsandbodiesof
SIPmessagesdescribedinRFC2543hasbeendeprecated.
23.1S/MIMECertificates
Thecertificatesthatareusedtoidentifyanend-userforthe
purposesofS/MIMEdifferfromthoseusedbyserversinoneimportant
respect-ratherthanassertingthattheidentityoftheholder
correspondstoaparticularhostname,thesecertificatesassertthat
theholderisidentifiedbyanend-useraddress.Thisaddressis
composedoftheconcatenationofthe"userinfo""@"and"domainname"
portionsofaSIPorSIPSURI(inotherwords,anemailaddressof
theform"[email protected]"),mostcommonlycorrespondingtoauser's
address-of-record.
Thesecertificatesarealsoassociatedwithkeysthatareusedto
signorencryptbodiesofSIPmessages.Bodiesaresignedwiththe
privatekeyofthesender(whomayincludetheirpublickeywiththe
messageasappropriate),butbodiesareencryptedwiththepublickey
oftheintendedrecipient.Obviously,sendersmusthave
foreknowledgeofthepublickeyofrecipientsinordertoencrypt
messagebodies.PublickeyscanbestoredwithinaUAonavirtual
keyring.
Rosenberg,et.al.StandardsTrack[Page201]
RFC3261SIP:SessionInitiationProtocolJune2002
EachuseragentthatsupportsS/MIMEMUSTcontainakeyring
specificallyforend-users'certificates.Thiskeyringshouldmap
betweenaddressesofrecordandcorrespondingcertificates.Over
time,usersSHOULDusethesamecertificatewhentheypopulatethe
originatingURIofsignaling(theFromheaderfield)withthesame
address-of-record.
Anymechanismsdependingontheexistenceofend-usercertificates
areseriouslylimitedinthatthereisvirtuallynoconsolidated
authoritytodaythatprovidescertificatesforend-userapplications.
However,usersSHOULDacquirecertificatesfromknownpublic
certificateauthorities.Asanalternative,usersMAYcreateself-
signedcertificates.Theimplicationsofself-signedcertificates
areexploredfurtherinSection26.4.2.Implementationsmayalsouse
pre-configuredcertificatesindeploymentsinwhichaprevioustrust
relationshipexistsbetweenallSIPentities.
Aboveandbeyondtheproblemofacquiringanend-usercertificate,
therearefewwell-knowncentralizeddirectoriesthatdistribute
end-usercertificates.However,theholderofacertificateSHOULD
publishtheircertificateinanypublicdirectoriesasappropriate.
Similarly,UACsSHOULDsupportamechanismforimporting(manuallyor
automatically)certificatesdiscoveredinpublicdirectories
correspondingtothetargetURIsofSIPrequests.
23.2S/MIMEKeyExchange
SIPitselfcanalsobeusedasameanstodistributepublickeysin
thefollowingmanner.
WhenevertheCMSSignedDatamessageisusedinS/MIMEforSIP,it
MUSTcontainthecertificatebearingthepublickeynecessaryto
verifythesignature.
WhenaUACsendsarequestcontaininganS/MIMEbodythatinitiatesa
dialog,orsendsanon-INVITErequestoutsidethecontextofa
dialog,theUACSHOULDstructurethebodyasanS/MIME
'multipart/signed'CMSSignedDatabody.IfthedesiredCMSservice
isEnvelopedData(andthepublickeyofthetargetuserisknown),
theUACSHOULDsendtheEnvelopedDatamessageencapsulatedwithina
SignedDatamessage.
WhenaUASreceivesarequestcontaininganS/MIMECMSbodythat
includesacertificate,theUASSHOULDfirstvalidatethe
certificate,ifpossible,withanyavailablerootcertificatesfor
certificateauthorities.TheUASSHOULDalsodeterminethesubject
ofthecertificate(forS/MIME,theSubjectAltNamewillcontainthe
appropriateidentity)andcomparethisvaluetotheFromheaderfield
Rosenberg,et.al.StandardsTrack[Page202]
RFC3261SIP:SessionInitiationProtocolJune2002
oftherequest.Ifthecertificatecannotbeverified,becauseitis
self-signed,orsignedbynoknownauthority,orifitisverifiable
butitssubjectdoesnotcorrespondtotheFromheaderfieldof
request,theUASMUSTnotifyitsuserofthestatusofthe
certificate(includingthesubjectofthecertificate,itssigner,
andanykeyfingerprintinformation)andrequestexplicitpermission
beforeproceeding.Ifthecertificatewassuccessfullyverifiedand
thesubjectofthecertificatecorrespondstotheFromheaderfield
oftheSIPrequest,oriftheuser(afternotification)explicitly
authorizestheuseofthecertificate,theUASSHOULDaddthis
certificatetoalocalkeyring,indexedbytheaddress-of-recordof
theholderofthecertificate.
WhenaUASsendsaresponsecontaininganS/MIMEbodythatanswers
thefirstrequestinadialog,oraresponsetoanon-INVITErequest
outsidethecontextofadialog,theUASSHOULDstructurethebodyas
anS/MIME'multipart/signed'CMSSignedDatabody.IfthedesiredCMS
serviceisEnvelopedData,theUASSHOULDsendtheEnvelopedData
messageencapsulatedwithinaSignedDatamessage.
WhenaUACreceivesaresponsecontaininganS/MIMECMSbodythat
includesacertificate,theUACSHOULDfirstvalidatethe
certificate,ifpossible,withanyappropriaterootcertificate.The
UACSHOULDalsodeterminethesubjectofthecertificateandcompare
thisvaluetotheTofieldoftheresponse;althoughthetwomayvery
wellbedifferent,andthisisnotnecessarilyindicativeofa
securitybreach.Ifthecertificatecannotbeverifiedbecauseitis
self-signed,orsignedbynoknownauthority,theUACMUSTnotifyits
userofthestatusofthecertificate(includingthesubjectofthe
certificate,itssignator,andanykeyfingerprintinformation)and
requestexplicitpermissionbeforeproceeding.Ifthecertificate
wassuccessfullyverified,andthesubjectofthecertificate
correspondstotheToheaderfieldintheresponse,oriftheuser
(afternotification)explicitlyauthorizestheuseofthe
certificate,theUACSHOULDaddthiscertificatetoalocalkeyring,
indexedbytheaddress-of-recordoftheholderofthecertificate.
IftheUAChadnottransmitteditsowncertificatetotheUASinany
previoustransaction,itSHOULDuseaCMSSignedDatabodyforits
nextrequestorresponse.
Onfutureoccasions,whentheUAreceivesrequestsorresponsesthat
containaFromheaderfieldcorrespondingtoavalueinitskeyring,
theUASHOULDcomparethecertificateofferedinthesemessageswith
theexistingcertificateinitskeyring.Ifthereisadiscrepancy,
theUAMUSTnotifyitsuserofachangeofthecertificate
(preferablyintermsthatindicatethatthisisapotentialsecurity
breach)andacquiretheuser'spermissionbeforecontinuingto
Rosenberg,et.al.StandardsTrack[Page203]
RFC3261SIP:SessionInitiationProtocolJune2002
processthesignaling.Iftheuserauthorizesthiscertificate,it
SHOULDbeaddedtothekeyringalongsideanypreviousvalue(s)for
thisaddress-of-record.
Notewellhowever,thatthiskeyexchangemechanismdoesnot
guaranteethesecureexchangeofkeyswhenself-signedcertificates,
orcertificatessignedbyanobscureauthority,areused-itis
vulnerabletowell-knownattacks.Intheopinionoftheauthors,
however,thesecurityitprovidesisproverbiallybetterthan
nothing;itisinfactcomparabletothewidelyusedSSHapplication.
TheselimitationsareexploredingreaterdetailinSection26.4.2.
IfaUAreceivesanS/MIMEbodythathasbeenencryptedwithapublic
keyunknowntotherecipient,itMUSTrejecttherequestwitha493
(Undecipherable)response.ThisresponseSHOULDcontainavalid
certificatefortherespondent(corresponding,ifpossible,toany
addressofrecordgivenintheToheaderfieldoftherejected
request)withinaMIMEbodywitha'certs-only'"smime-type"
parameter.
A493(Undecipherable)sentwithoutanycertificateindicatesthat
therespondentcannotorwillnotutilizeS/MIMEencryptedmessages,
thoughtheymaystillsupportS/MIMEsignatures.
NotethatauseragentthatreceivesarequestcontaininganS/MIME
bodythatisnotoptional(withaContent-Dispositionheader
"handling"parameterof"required")MUSTrejecttherequestwitha
415UnsupportedMediaTyperesponseiftheMIMEtypeisnot
understood.AuseragentthatreceivessucharesponsewhenS/MIME
issentSHOULDnotifyitsuserthattheremotedevicedoesnot
supportS/MIME,anditMAYsubsequentlyresendtherequestwithout
S/MIME,ifappropriate;however,this415responsemayconstitutea
downgradeattack.
IfauseragentsendsanS/MIMEbodyinarequest,butreceivesa
responsethatcontainsaMIMEbodythatisnotsecured,theUAC
SHOULDnotifyitsuserthatthesessioncouldnotbesecured.
However,ifauseragentthatsupportsS/MIMEreceivesarequestwith
anunsecuredbody,itSHOULDNOTrespondwithasecuredbody,butif
itexpectsS/MIMEfromthesender(forexample,becausethesender's
Fromheaderfieldvaluecorrespondstoanidentityonitskeychain),
theUASSHOULDnotifyitsuserthatthesessioncouldnotbesecured.
Anumberofconditionsthatariseintheprevioustextcallforthe
notificationoftheuserwhenananomalouscertificate-management
eventoccurs.Usersmightwellaskwhattheyshoulddounderthese
circumstances.Firstandforemost,anunexpectedchangeina
certificate,oranabsenceofsecuritywhensecurityisexpected,are
Rosenberg,et.al.StandardsTrack[Page204]
RFC3261SIP:SessionInitiationProtocolJune2002
causesforcautionbutnotnecessarilyindicationsthatanattackis
inprogress.Usersmightabortanyconnectionattemptorrefusea
connectionrequesttheyhavereceived;intelephonyparlance,they
couldhangupandcallback.Usersmaywishtofindanalternate
meanstocontacttheotherpartyandconfirmthattheirkeyhas
legitimatelychanged.Notethatusersaresometimescompelledto
changetheircertificates,forexamplewhentheysuspectthatthe
secrecyoftheirprivatekeyhasbeencompromised.Whentheir
privatekeyisnolongerprivate,usersmustlegitimatelygeneratea
newkeyandre-establishtrustwithanyusersthatheldtheirold
key.
Finally,ifduringthecourseofadialogaUAreceivesacertificate
inaCMSSignedDatamessagethatdoesnotcorrespondwiththe
certificatespreviouslyexchangedduringadialog,theUAMUSTnotify
itsuserofthechange,preferablyintermsthatindicatethatthis
isapotentialsecuritybreach.
23.3SecuringMIMEbodies
TherearetwotypesofsecureMIMEbodiesthatareofinterestto
SIP:useofthesebodiesshouldfollowtheS/MIMEspecification[24]
withafewvariations.
o"multipart/signed"MUSTbeusedonlywithCMSdetached
signatures.
Thisallowsbackwardscompatibilitywithnon-S/MIME-
compliantrecipients.
oS/MIMEbodiesSHOULDhaveaContent-Dispositionheaderfield,
andthevalueofthe"handling"parameterSHOULDbe"required."
oIfaUAChasnocertificateonitskeyringassociatedwiththe
address-of-recordtowhichitwantstosendarequest,it
cannotsendanencrypted"application/pkcs7-mime"MIMEmessage.
UACsMAYsendaninitialrequestsuchasanOPTIONSmessage
withaCMSdetachedsignatureinordertosolicitthe
certificateoftheremoteside(thesignatureSHOULDbeovera
"message/sip"bodyofthetypedescribedinSection23.4).
NotethatfuturestandardizationworkonS/MIMEmaydefine
non-certificatebasedkeys.
oSendersofS/MIMEbodiesSHOULDusethe"SMIMECapabilities"
(seeSection2.5.2of[24])attributetoexpresstheir
capabilitiesandpreferencesforfurthercommunications.Note
especiallythatsendersMAYusethe"preferSignedData"
Rosenberg,et.al.StandardsTrack[Page205]
RFC3261SIP:SessionInitiationProtocolJune2002
capabilitytoencouragereceiverstorespondwithCMS
SignedDatamessages(forexample,whensendinganOPTIONS
requestasdescribedabove).
oS/MIMEimplementationsMUSTataminimumsupportSHA1asa
digitalsignaturealgorithm,and3DESasanencryption
algorithm.AllothersignatureandencryptionalgorithmsMAY
besupported.Implementationscannegotiatesupportforthese
algorithmswiththe"SMIMECapabilities"attribute.
oEachS/MIMEbodyinaSIPmessageSHOULDbesignedwithonly
onecertificate.IfaUAreceivesamessagewithmultiple
signatures,theoutermostsignatureshouldbetreatedasthe
singlecertificateforthisbody.ParallelsignaturesSHOULD
NOTbeused.
ThefollowingisanexampleofanencryptedS/MIMESDPbody
withinaSIPmessage:
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Max-Forwards:70
Contact:
Content-Type:application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Disposition:attachment;filename=smime.p7m
handling=required
*******************************************************
*Content-Type:application/sdp*
**
*v=0*
*o=alice536557652353687637INIP4pc33.atlanta.com*
*s=-*
*t=00*
*c=INIP4pc33.atlanta.com*
*m=audio3456RTP/AVP01399*
*a=rtpmap:0PCMU/8000*
*******************************************************
Rosenberg,et.al.StandardsTrack[Page206]
RFC3261SIP:SessionInitiationProtocolJune2002
23.4SIPHeaderPrivacyandIntegrityusingS/MIME:TunnelingSIP
Asameansofprovidingsomedegreeofend-to-endauthentication,
integrityorconfidentialityforSIPheaderfields,S/MIMEcan
encapsulateentireSIPmessageswithinMIMEbodiesoftype
"message/sip"andthenapplyMIMEsecuritytothesebodiesinthe
samemannerastypicalSIPbodies.TheseencapsulatedSIPrequests
andresponsesdonotconstituteaseparatedialogortransaction,
theyareacopyofthe"outer"messagethatisusedtoverify
integrityortosupplyadditionalinformation.
IfaUASreceivesarequestthatcontainsatunneled"message/sip"
S/MIMEbody,itSHOULDincludeatunneled"message/sip"bodyinthe
responsewiththesamesmime-type.
AnytraditionalMIMEbodies(suchasSDP)SHOULDbeattachedtothe
"inner"messagesothattheycanalsobenefitfromS/MIMEsecurity.
Notethat"message/sip"bodiescanbesentasapartofaMIME
"multipart/mixed"bodyifanyunsecuredMIMEtypesshouldalsobe
transmittedinarequest.
23.4.1IntegrityandConfidentialityPropertiesofSIPHeaders
WhentheS/MIMEintegrityorconfidentialitymechanismsareused,
theremaybediscrepanciesbetweenthevaluesinthe"inner"message
andvaluesinthe"outer"message.Therulesforhandlinganysuch
differencesforalloftheheaderfieldsdescribedinthisdocument
aregiveninthissection.
Notethatforthepurposesofloosetimestamping,allSIPmessages
thattunnel"message/sip"SHOULDcontainaDateheaderinboththe
"inner"and"outer"headers.
23.4.1.1Integrity
Wheneverintegritychecksareperformed,theintegrityofaheader
fieldshouldbedeterminedbymatchingthevalueoftheheaderfield
inthesignedbodywiththatinthe"outer"messagesusingthe
comparisonrulesofSIPasdescribedin20.
Headerfieldsthatcanbelegitimatelymodifiedbyproxyserversare:
Request-URI,Via,Record-Route,Route,Max-Forwards,andProxy-
Authorization.Iftheseheaderfieldsarenotintactend-to-end,
implementationsSHOULDNOTconsiderthisabreachofsecurity.
Changestoanyotherheaderfieldsdefinedinthisdocument
constituteanintegrityviolation;usersMUSTbenotifiedofa
discrepancy.
Rosenberg,et.al.StandardsTrack[Page207]
RFC3261SIP:SessionInitiationProtocolJune2002
23.4.1.2Confidentiality
Whenmessagesareencrypted,headerfieldsmaybeincludedinthe
encryptedbodythatarenotpresentinthe"outer"message.
Someheaderfieldsmustalwayshaveaplaintextversionbecausethey
arerequiredheaderfieldsinrequestsandresponses-theseinclude:
To,From,Call-ID,CSeq,Contact.Whileitisprobablynotusefulto
provideanencryptedalternativefortheCall-ID,CSeq,orContact,
providinganalternativetotheinformationinthe"outer"ToorFrom
ispermitted.Notethatthevaluesinanencryptedbodyarenotused
forthepurposesofidentifyingtransactionsordialogs-theyare
merelyinformational.IftheFromheaderfieldinanencryptedbody
differsfromthevalueinthe"outer"message,thevaluewithinthe
encryptedbodySHOULDbedisplayedtotheuser,butMUSTNOTbeused
inthe"outer"headerfieldsofanyfuturemessages.
Primarily,auseragentwillwanttoencryptheaderfieldsthathave
anend-to-endsemantic,including:Subject,Reply-To,Organization,
Accept,Accept-Encoding,Accept-Language,Alert-Info,Error-Info,
Authentication-Info,Expires,In-Reply-To,Require,Supported,
Unsupported,Retry-After,User-Agent,Server,andWarning.Ifanyof
theseheaderfieldsarepresentinanencryptedbody,theyshouldbe
usedinsteadofany"outer"headerfields,whetherthisentails
displayingtheheaderfieldvaluestousersorsettinginternal
statesintheUA.TheySHOULDNOThoweverbeusedinthe"outer"
headersofanyfuturemessages.
Ifpresent,theDateheaderfieldMUSTalwaysbethesameinthe
"inner"and"outer"headers.
SinceMIMEbodiesareattachedtothe"inner"message,
implementationswillusuallyencryptMIME-specificheaderfields,
including:MIME-Version,Content-Type,Content-Length,Content-
Language,Content-EncodingandContent-Disposition.The"outer"
messagewillhavetheproperMIMEheaderfieldsforS/MIMEbodies.
Theseheaderfields(andanyMIMEbodiestheypreface)shouldbe
treatedasnormalMIMEheaderfieldsandbodiesreceivedinaSIP
message.
Itisnotparticularlyusefultoencryptthefollowingheaderfields:
Min-Expires,Timestamp,Authorization,Priority,andWWW-
Authenticate.Thiscategoryalsoincludesthoseheaderfieldsthat
canbechangedbyproxyservers(describedintheprecedingsection).
UAsSHOULDneverincludetheseinan"inner"messageiftheyarenot
Rosenberg,et.al.StandardsTrack[Page208]
RFC3261SIP:SessionInitiationProtocolJune2002
includedinthe"outer"message.UAsthatreceiveanyofthese
headerfieldsinanencryptedbodySHOULDignoretheencrypted
values.
NotethatextensionstoSIPmaydefineadditionalheaderfields;the
authorsoftheseextensionsshoulddescribetheintegrityand
confidentialitypropertiesofsuchheaderfields.IfaSIPUA
encountersanunknownheaderfieldwithanintegrityviolation,it
MUSTignoretheheaderfield.
23.4.2TunnelingIntegrityandAuthentication
TunnelingSIPmessageswithinS/MIMEbodiescanprovideintegrityfor
SIPheaderfieldsiftheheaderfieldsthatthesenderwishesto
securearereplicatedina"message/sip"MIMEbodysignedwithaCMS
detachedsignature.
Providedthatthe"message/sip"bodycontainsatleastthe
fundamentaldialogidentifiers(To,From,Call-ID,CSeq),thena
signedMIMEbodycanprovidelimitedauthentication.Atthevery
least,ifthecertificateusedtosignthebodyisunknowntothe
recipientandcannotbeverified,thesignaturecanbeusedto
ascertainthatalaterrequestinadialogwastransmittedbythe
samecertificate-holderthatinitiatedthedialog.Iftherecipient
ofthesignedMIMEbodyhassomestrongerincentivetotrustthe
certificate(theywereabletovalidateit,theyacquireditfroma
trustedrepository,ortheyhaveuseditfrequently)thenthe
signaturecanbetakenasastrongerassertionoftheidentityofthe
subjectofthecertificate.
Inordertoeliminatepossibleconfusionsabouttheadditionor
subtractionofentireheaderfields,sendersSHOULDreplicateall
headerfieldsfromtherequestwithinthesignedbody.Anymessage
bodiesthatrequireintegrityprotectionMUSTbeattachedtothe
"inner"message.
IfaDateheaderispresentinamessagewithasignedbody,the
recipientSHOULDcomparetheheaderfieldvaluewithitsowninternal
clock,ifapplicable.Ifasignificanttimediscrepancyisdetected
(ontheorderofanhourormore),theuseragentSHOULDalertthe
usertotheanomaly,andnotethatitisapotentialsecuritybreach.
Ifanintegrityviolationinamessageisdetectedbyitsrecipient,
themessageMAYberejectedwitha403(Forbidden)responseifitis
arequest,oranyexistingdialogMAYbeterminated.UAsSHOULD
notifyusersofthiscircumstanceandrequestexplicitguidanceon
howtoproceed.
Rosenberg,et.al.StandardsTrack[Page209]
RFC3261SIP:SessionInitiationProtocolJune2002
Thefollowingisanexampleoftheuseofatunneled"message/sip"
body:
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Max-Forwards:70
Date:Thu,21Feb200213:02:03GMT
Contact:
Content-Type:multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary=boundary42
Content-Length:568
--boundary42
Content-Type:message/sip
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Max-Forwards:70
Date:Thu,21Feb200213:02:03GMT
Contact:
Content-Type:application/sdp
Content-Length:147
v=0
o=UserA28908445262890844526INIP4here.com
s=SessionSDP
c=INIP4pc33.atlanta.com
t=00
m=audio49172RTP/AVP0
a=rtpmap:0PCMU/8000
--boundary42
Content-Type:application/pkcs7-signature;name=smime.p7s
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7s;
handling=required
Rosenberg,et.al.StandardsTrack[Page210]
RFC3261SIP:SessionInitiationProtocolJune2002
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42-
23.4.3TunnelingEncryption
Itmayalsobedesirabletousethismechanismtoencrypta
"message/sip"MIMEbodywithinaCMSEnvelopedDatamessageS/MIME
body,butinpractice,mostheaderfieldsareofatleastsomeuseto
thenetwork;thegeneraluseofencryptionwithS/MIMEistosecure
messagebodieslikeSDPratherthanmessageheaders.Some
informationalheaderfields,suchastheSubjectorOrganization
couldperhapswarrantend-to-endsecurity.Headersdefinedbyfuture
SIPapplicationsmightalsorequireobfuscation.
Anotherpossibleapplicationofencryptingheaderfieldsisselective
anonymity.ArequestcouldbeconstructedwithaFromheaderfield
thatcontainsnopersonalinformation(forexample,
sip:[email protected]).However,asecondFromheader
fieldcontainingthegenuineaddress-of-recordoftheoriginator
couldbeencryptedwithina"message/sip"MIMEbodywhereitwill
onlybevisibletotheendpointsofadialog.
Notethatifthismechanismisusedforanonymity,theFromheader
fieldwillnolongerbeusablebytherecipientofamessageasan
indextotheircertificatekeychainforretrievingtheproper
S/MIMEkeytoassociatedwiththesender.Themessagemustfirst
bedecrypted,andthe"inner"FromheaderfieldMUSTbeusedasan
index.
Inordertoprovideend-to-endintegrity,encrypted"message/sip"
MIMEbodiesSHOULDbesignedbythesender.Thiscreatesa
"multipart/signed"MIMEbodythatcontainsanencryptedbodyanda
signature,bothoftype"application/pkcs7-mime".
Rosenberg,et.al.StandardsTrack[Page211]
RFC3261SIP:SessionInitiationProtocolJune2002
Inthefollowingexample,ofanencryptedandsignedmessage,the
textboxedinasterisks("*")isencrypted:
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
To:Bob
From:Anonymous;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Max-Forwards:70
Date:Thu,21Feb200213:02:03GMT
Contact:
Content-Type:multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1;boundary=boundary42
Content-Length:568
--boundary42
Content-Type:application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7m
handling=required
Content-Length:231
***********************************************************
*Content-Type:message/sip*
**
*INVITEsip:[email protected]/2.0*
*Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8*
*To:Bob*
*From:Alice;tag=1928301774*
*Call-ID:a84b4c76e66710*
*CSeq:314159INVITE*
*Max-Forwards:70*
*Date:Thu,21Feb200213:02:03GMT*
*Contact:*
**
*Content-Type:application/sdp*
**
*v=0*
*o=alice536557652353687637INIP4pc33.atlanta.com*
*s=SessionSDP*
*t=00*
*c=INIP4pc33.atlanta.com*
*m=audio3456RTP/AVP01399*
*a=rtpmap:0PCMU/8000*
***********************************************************
Rosenberg,et.al.StandardsTrack[Page212]
RFC3261SIP:SessionInitiationProtocolJune2002
--boundary42
Content-Type:application/pkcs7-signature;name=smime.p7s
Content-Transfer-Encoding:base64
Content-Disposition:attachment;filename=smime.p7s;
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42-
24Examples
Inthefollowingexamples,weoftenomitthemessagebodyandthe
correspondingContent-LengthandContent-Typeheaderfieldsfor
brevity.
24.1Registration
Bobregistersonstart-up.ThemessageflowisshowninFigure9.
Notethattheauthenticationusuallyrequiredforregistrationisnot
shownforsimplicity.
biloxi.comBob's
registrarsoftphone
||
|REGISTERF1|
||
Figure9:SIPRegistrationExample
F1REGISTERBob->Registrar
REGISTERsip:registrar.biloxi.comSIP/2.0
Via:SIP/2.0/UDPbobspc.biloxi.com:5060;branch=z9hG4bKnashds7
Max-Forwards:70
To:Bob
From:Bob;tag=456248
Call-ID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Contact:
Expires:7200
Content-Length:0
Rosenberg,et.al.StandardsTrack[Page213]
RFC3261SIP:SessionInitiationProtocolJune2002
Theregistrationexpiresaftertwohours.Theregistrarresponds
witha200OK:
F2200OKRegistrar->Bob
SIP/2.0200OK
Via:SIP/2.0/UDPbobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To:Bob;tag=2493k59kd
From:Bob;tag=456248
Call-ID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Contact:
Expires:7200
Content-Length:0
24.2SessionSetup
Thisexamplecontainsthefulldetailsoftheexamplesessionsetup
inSection4.ThemessageflowisshowninFigure1.Notethat
theseflowsshowtheminimumrequiredsetofheaderfields-some
otherheaderfieldssuchasAllowandSupportedwouldnormallybe
present.
F1INVITEAlice->atlanta.comproxy
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards:70
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:142
(Alice'sSDPnotshown)
Rosenberg,et.al.StandardsTrack[Page214]
RFC3261SIP:SessionInitiationProtocolJune2002
F2100Tryingatlanta.comproxy->Alice
SIP/2.0100Trying
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Content-Length:0
F3INVITEatlanta.comproxy->biloxi.comproxy
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards:69
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:142
(Alice'sSDPnotshown)
F4100Tryingbiloxi.comproxy->atlanta.comproxy
SIP/2.0100Trying
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Content-Length:0
Rosenberg,et.al.StandardsTrack[Page215]
RFC3261SIP:SessionInitiationProtocolJune2002
F5INVITEbiloxi.comproxy->Bob
INVITEsip:[email protected]/2.0
Via:SIP/2.0/UDPserver10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards:68
To:Bob
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:142
(Alice'sSDPnotshown)
F6180RingingBob->biloxi.comproxy
SIP/2.0180Ringing
Via:SIP/2.0/UDPserver10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
Contact:
CSeq:314159INVITE
Content-Length:0
F7180Ringingbiloxi.comproxy->atlanta.comproxy
SIP/2.0180Ringing
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
Contact:
CSeq:314159INVITE
Content-Length:0
Rosenberg,et.al.StandardsTrack[Page216]
RFC3261SIP:SessionInitiationProtocolJune2002
F8180Ringingatlanta.comproxy->Alice
SIP/2.0180Ringing
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
Contact:
CSeq:314159INVITE
Content-Length:0
F9200OKBob->biloxi.comproxy
SIP/2.0200OK
Via:SIP/2.0/UDPserver10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.3
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:131
(Bob'sSDPnotshown)
F10200OKbiloxi.comproxy->atlanta.comproxy
SIP/2.0200OK
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:131
(Bob'sSDPnotshown)
Rosenberg,et.al.StandardsTrack[Page217]
RFC3261SIP:SessionInitiationProtocolJune2002
F11200OKatlanta.comproxy->Alice
SIP/2.0200OK
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159INVITE
Contact:
Content-Type:application/sdp
Content-Length:131
(Bob'sSDPnotshown)
F12ACKAlice->Bob
ACKsip:[email protected]/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards:70
To:Bob;tag=a6c85cf
From:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:314159ACK
Content-Length:0
ThemediasessionbetweenAliceandBobisnowestablished.
Bobhangsupfirst.NotethatBob'sSIPphonemaintainsitsownCSeq
numberingspace,which,inthisexample,beginswith231.SinceBob
ismakingtherequest,theToandFromURIsandtagshavebeen
swapped.
F13BYEBob->Alice
BYEsip:[email protected]/2.0
Via:SIP/2.0/UDP192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards:70
From:Bob;tag=a6c85cf
To:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:231BYE
Content-Length:0
Rosenberg,et.al.StandardsTrack[Page218]
RFC3261SIP:SessionInitiationProtocolJune2002
F14200OKAlice->Bob
SIP/2.0200OK
Via:SIP/2.0/UDP192.0.2.4;branch=z9hG4bKnashds10
From:Bob;tag=a6c85cf
To:Alice;tag=1928301774
Call-ID:a84b4c76e66710
CSeq:231BYE
Content-Length:0
TheSIPCallFlowsdocument[40]containsfurtherexamplesofSIP
messages.
25AugmentedBNFfortheSIPProtocol
Allofthemechanismsspecifiedinthisdocumentaredescribedin
bothproseandanaugmentedBackus-NaurForm(BNF)definedinRFC
2234[10].Section 6.1ofRFC2234definesasetofcorerulesthat
areusedbythisspecification,andnotrepeatedhere.Implementers
needtobefamiliarwiththenotationandcontentofRFC2234in
ordertounderstandthisspecification.Certainbasicrulesarein
uppercase,suchasSP,LWS,HTAB,CRLF,DIGIT,ALPHA,etc.Angle
bracketsareusedwithindefinitionstoclarifytheuseofrule
names.
Theuseofsquarebracketsisredundantsyntactically.Itisusedas
asemantichintthatthespecificparameterisoptionaltouse.
25.1BasicRules
Thefollowingrulesareusedthroughoutthisspecificationto
describebasicparsingconstructs.TheUS-ASCIIcodedcharacterset
isdefinedbyANSIX3.4-1986.
alphanum=ALPHA/DIGIT
Rosenberg,et.al.StandardsTrack[Page219]
RFC3261SIP:SessionInitiationProtocolJune2002
SeveralrulesareincorporatedfromRFC2396[5]butareupdatedto
makethemcompliantwithRFC2234[10].Theseinclude:
reserved=";"/"/"/"?"/":"/"@"/"&"/"="/"+"
/"$"/","
unreserved=alphanum/mark
mark="-"/"_"/"."/"!"/"~"/"*"/"'"
/"("/")"
escaped="%"HEXDIGHEXDIG
SIPheaderfieldvaluescanbefoldedontomultiplelinesifthe
continuationlinebeginswithaspaceorhorizontaltab.Alllinear
whitespace,includingfolding,hasthesamesemanticsasSP.A
recipientMAYreplaceanylinearwhitespacewithasingleSPbefore
interpretingthefieldvalueorforwardingthemessagedownstream.
ThisisintendedtobehaveexactlyasHTTP/1.1asdescribedinRFC
2616[8].TheSWSconstructisusedwhenlinearwhitespaceis
optional,generallybetweentokensandseparators.
LWS=[*WSPCRLF]1*WSP;linearwhitespace
SWS=[LWS];sepwhitespace
Toseparatetheheadernamefromtherestofvalue,acolonisused,
which,bytheaboverule,allowswhitespacebefore,butnoline
break,andwhitespaceafter,includingalinebreak.TheHCOLON
definesthisconstruct.
HCOLON=*(SP/HTAB)":"SWS
TheTEXT-UTF8ruleisonlyusedfordescriptivefieldcontentsand
valuesthatarenotintendedtobeinterpretedbythemessageparser.
Wordsof*TEXT-UTF8containcharactersfromtheUTF-8charset(RFC
2279[7]).TheTEXT-UTF8-TRIMruleisusedfordescriptivefield
contentsthatarentquotedstrings,whereleadingandtrailingLWS
isnotmeaningful.Inthisregard,SIPdiffersfromHTTP,whichuses
theISO8859-1characterset.
TEXT-UTF8-TRIM=1*TEXT-UTF8char*(*LWSTEXT-UTF8char)
TEXT-UTF8char=%x21-7E/UTF8-NONASCII
UTF8-NONASCII=%xC0-DF1UTF8-CONT
/%xE0-EF2UTF8-CONT
/%xF0-F73UTF8-CONT
/%xF8-Fb4UTF8-CONT
/%xFC-FD5UTF8-CONT
UTF8-CONT=%x80-BF
Rosenberg,et.al.StandardsTrack[Page220]
RFC3261SIP:SessionInitiationProtocolJune2002
ACRLFisallowedinthedefinitionofTEXT-UTF8-TRIMonlyaspartof
aheaderfieldcontinuation.ItisexpectedthatthefoldingLWS
willbereplacedwithasingleSPbeforeinterpretationoftheTEXT-
UTF8-TRIMvalue.
Hexadecimalnumericcharactersareusedinseveralprotocolelements.
Someelements(authentication)forcehexalphastobelowercase.
LHEX=DIGIT/%x61-66;lowercasea-f
ManySIPheaderfieldvaluesconsistofwordsseparatedbyLWSor
specialcharacters.Unlessotherwisestated,tokensarecase-
insensitive.ThesespecialcharactersMUSTbeinaquotedstringto
beusedwithinaparametervalue.Thewordconstructisusedin
Call-IDtoallowmostseparatorstobeused.
token=1*(alphanum/"-"/"."/"!"/"%"/"*"
/"_"/"+"/"`"/"'"/"~")
separators="("/")"/""/"@"/
","/";"/":"/"\"/DQUOTE/
"/"/"["/"]"/"?"/"="/
"{"/"}"/SP/HTAB
word=1*(alphanum/"-"/"."/"!"/"%"/"*"/
"_"/"+"/"`"/"'"/"~"/
"("/")"/""/
":"/"\"/DQUOTE/
"/"/"["/"]"/"?"/
"{"/"}")
Whentokensareusedorseparatorsareusedbetweenelements,
whitespaceisoftenallowedbeforeorafterthesecharacters:
STAR=SWS"*"SWS;asterisk
SLASH=SWS"/"SWS;slash
EQUAL=SWS"="SWS;equal
LPAREN=SWS"("SWS;leftparenthesis
RPAREN=SWS")"SWS;rightparenthesis
RAQUOT=">"SWS;rightanglequote
LAQUOT=SWS".
CarolreceivestheredirectionresponseovertheTLSconnectionshe
establishedwiththebiloxiproxy,soshetruststheveracityofthe
contactaddress.
CarolSHOULDthenestablishaTCPconnectionwiththedesignated
addressandsendanewINVITEwithaRequest-URIcontainingthe
receivedcontactaddress(recomputingthesignatureinthebodyas
therequestisreadied).BobreceivesthisINVITEonaninsecure
interface,buthisUAinspectsand,inthisinstance,recognizesthe
Fromheaderfieldoftherequestandsubsequentlymatchesalocally
cachedcertificatewiththeonepresentedinthesignatureofthe
bodyoftheINVITE.Herepliesinsimilarfashion,authenticating
himselftoCarol,andasecuredialogbegins.
SometimesfirewallsorNATsinanadministrativedomaincould
precludetheestablishmentofadirectTCPconnectiontoaUA.In
thesecases,proxyserverscouldalsopotentiallyrelayrequests
toUAsinawaythathasnotrustimplications(forexample,
forgoinganexistingTLSconnectionandforwardingtherequest
overcleartextTCP)aslocalpolicydictates.
26.3.2.4DoSProtection
Inordertominimizetheriskofadenial-of-serviceattackagainst
architecturesusingthesesecuritysolutions,implementersshould
takenoteofthefollowingguidelines.
WhenthehostonwhichaSIPproxyserverisoperatingisroutable
fromthepublicInternet,itSHOULDbedeployedinanadministrative
domainwithdefensiveoperationalpolicies(blockingsource-routed
traffic,preferablyfilteringpingtraffic).BothTLSandIPSeccan
alsomakeuseofbastionhostsattheedgesofadministrativedomains
thatparticipateinthesecurityassociationstoaggregatesecure
tunnelsandsockets.Thesebastionhostscanalsotakethebruntof
denial-of-serviceattacks,ensuringthatSIPhostswithinthe
administrativedomainarenotencumberedwithsuperfluousmessaging.
Rosenberg,et.al.StandardsTrack[Page246]
RFC3261SIP:SessionInitiationProtocolJune2002
Nomatterwhatsecuritysolutionsaredeployed,floodsofmessages
directedatproxyserverscanlockupproxyserverresourcesand
preventdesirabletrafficfromreachingitsdestination.Thereisa
computationalexpenseassociatedwithprocessingaSIPtransactionat
aproxyserver,andthatexpenseisgreaterforstatefulproxy
serversthanitisforstatelessproxyservers.Therefore,stateful
proxiesaremoresusceptibletofloodingthanstatelessproxy
servers.
UAsandproxyserversSHOULDchallengequestionablerequestswith
onlyasingle401(Unauthorized)or407(ProxyAuthentication
Required),forgoingthenormalresponseretransmissionalgorithm,and
thusbehavingstatelesslytowardsunauthenticatedrequests.
Retransmittingthe401(Unauthorized)or407(ProxyAuthentication
Required)statusresponseamplifiestheproblemofanattacker
usingafalsifiedheaderfieldvalue(suchasVia)todirect
traffictoathirdparty.
Insummary,themutualauthenticationofproxyserversthrough
mechanismssuchasTLSsignificantlyreducesthepotentialforrogue
intermediariestointroducefalsifiedrequestsorresponsesthatcan
denyservice.Thiscommensuratelymakesitharderforattackersto
makeinnocentSIPnodesintoagentsofamplification.
26.4Limitations
Althoughthesesecuritymechanisms,whenappliedinajudicious
manner,canthwartmanythreats,therearelimitationsinthescope
ofthemechanismsthatmustbeunderstoodbyimplementersandnetwork
operators.
26.4.1HTTPDigest
OneoftheprimarylimitationsofusingHTTPDigestinSIPisthat
theintegritymechanismsinDigestdonotworkverywellforSIP.
Specifically,theyofferprotectionoftheRequest-URIandthemethod
ofamessage,butnotforanyoftheheaderfieldsthatUAswould
mostlikelywishtosecure.
TheexistingreplayprotectionmechanismsdescribedinRFC2617also
havesomelimitationsforSIP.Thenext-noncemechanism,for
example,doesnotsupportpipelinedrequests.Thenonce-count
mechanismshouldbeusedforreplayprotection.
AnotherlimitationofHTTPDigestisthescopeofrealms.Digestis
valuablewhenauserwantstoauthenticatethemselvestoaresource
withwhichtheyhaveapre-existingassociation,likeaservice
Rosenberg,et.al.StandardsTrack[Page247]
RFC3261SIP:SessionInitiationProtocolJune2002
providerofwhichtheuserisacustomer(whichisquiteacommon
scenarioandthusDigestprovidesanextremelyusefulfunction).By
wayofcontrast,thescopeofTLSisinterdomainormultirealm,since
certificatesareoftengloballyverifiable,sothattheUAcan
authenticatetheserverwithnopre-existingassociation.
26.4.2S/MIME
ThelargestoutstandingdefectwiththeS/MIMEmechanismisthelack
ofaprevalentpublickeyinfrastructureforendusers.Ifself-
signedcertificates(orcertificatesthatcannotbeverifiedbyone
oftheparticipantsinadialog)areused,theSIP-basedkeyexchange
mechanismdescribedinSection23.2issusceptibletoaman-in-the-
middleattackwithwhichanattackercanpotentiallyinspectand
modifyS/MIMEbodies.Theattackerneedstointerceptthefirst
exchangeofkeysbetweenthetwopartiesinadialog,removethe
existingCMS-detachedsignaturesfromtherequestandresponse,and
insertadifferentCMS-detachedsignaturecontainingacertificate
suppliedbytheattacker(butwhichseemstobeacertificateforthe
properaddress-of-record).Eachpartywillthinktheyhaveexchanged
keyswiththeother,wheninfacteachhasthepublickeyofthe
attacker.
Itisimportanttonotethattheattackercanonlyleveragethis
vulnerabilityonthefirstexchangeofkeysbetweentwoparties-on
subsequentoccasions,thealterationofthekeywouldbenoticeable
totheUAs.Itwouldalsobedifficultfortheattackertoremainin
thepathofallfuturedialogsbetweenthetwopartiesovertime(as
potentiallydays,weeks,oryearspass).
SSHissusceptibletothesameman-in-the-middleattackonthefirst
exchangeofkeys;however,itiswidelyacknowledgedthatwhileSSH
isnotperfect,itdoesimprovethesecurityofconnections.Theuse
ofkeyfingerprintscouldprovidesomeassistancetoSIP,justasit
doesforSSH.Forexample,iftwopartiesuseSIPtoestablisha
voicecommunicationssession,eachcouldreadoffthefingerprintof
thekeytheyreceivedfromtheother,whichcouldbecomparedagainst
theoriginal.Itwouldcertainlybemoredifficultfortheman-in-
the-middletoemulatethevoicesoftheparticipantsthantheir
signaling(apracticethatwasusedwiththeClipperchip-based
securetelephone).
TheS/MIMEmechanismallowsUAstosendencryptedrequestswithout
preambleiftheypossessacertificateforthedestinationaddress-
of-recordontheirkeyring.However,itispossiblethatany
particulardeviceregisteredforanaddress-of-recordwillnothold
thecertificatethathasbeenpreviouslyemployedbythedevice's
currentuser,andthatitwillthereforebeunabletoprocessan
Rosenberg,et.al.StandardsTrack[Page248]
RFC3261SIP:SessionInitiationProtocolJune2002
encryptedrequestproperly,whichcouldleadtosomeavoidableerror
signaling.Thisisespeciallylikelywhenanencryptedrequestis
forked.
ThekeysassociatedwithS/MIMEaremostusefulwhenassociatedwith
aparticularuser(anaddress-of-record)ratherthanadevice(aUA).
Whenusersmovebetweendevices,itmaybedifficulttotransport
privatekeyssecurelybetweenUAs;howsuchkeysmightbeacquiredby
adeviceisoutsidethescopeofthisdocument.
Another,moreprosaicdifficultywiththeS/MIMEmechanismisthatit
canresultinverylargemessages,especiallywhentheSIPtunneling
mechanismdescribedinSection23.4isused.Forthatreason,itis
RECOMMENDEDthatTCPshouldbeusedasatransportprotocolwhen
S/MIMEtunnelingisemployed.
26.4.3TLS
ThemostcommonlyvoicedconcernaboutTLSisthatitcannotrunover
UDP;TLSrequiresaconnection-orientedunderlyingtransport
protocol,whichforthepurposesofthisdocumentmeansTCP.
Itmayalsobearduousforalocaloutboundproxyserverand/or
registrartomaintainmanysimultaneouslong-livedTLSconnections
withnumerousUAs.Thisintroducessomevalidscalabilityconcerns,
especiallyforintensiveciphersuites.Maintainingredundancyof
long-livedTLSconnections,especiallywhenaUAissolely
responsiblefortheirestablishment,couldalsobecumbersome.
TLSonlyallowsSIPentitiestoauthenticateserverstowhichthey
areadjacent;TLSoffersstrictlyhop-by-hopsecurity.NeitherTLS,
noranyothermechanismspecifiedinthisdocument,allowsclientsto
authenticateproxyserverstowhomtheycannotformadirectTCP
connection.
26.4.4SIPSURIs
ActuallyusingTLSoneverysegmentofarequestpathentailsthat
theterminatingUASmustbereachableoverTLS(perhapsregistering
withaSIPSURIasacontactaddress).Thisisthepreferreduseof
SIPS.Manyvalidarchitectures,however,useTLStosecurepartof
therequestpath,butrelyonsomeothermechanismforthefinalhop
toaUAS,forexample.ThusSIPScannotguaranteethatTLSusage
willbetrulyend-to-end.NotethatsincemanyUAswillnotaccept
incomingTLSconnections,eventhoseUAsthatdosupportTLSmaybe
requiredtomaintainpersistentTLSconnectionsasdescribedinthe
TLSlimitationssectionaboveinordertoreceiverequestsoverTLS
asaUAS.
Rosenberg,et.al.StandardsTrack[Page249]
RFC3261SIP:SessionInitiationProtocolJune2002
LocationservicesarenotrequiredtoprovideaSIPSbindingfora
SIPSRequest-URI.Althoughlocationservicesarecommonlypopulated
byuserregistrations(asdescribedinSection10.2.1),variousother
protocolsandinterfacescouldconceivablysupplycontactaddresses
foranAOR,andthesetoolsarefreetomapSIPSURIstoSIPURIsas
appropriate.Whenqueriedforbindings,alocationservicereturns
itscontactaddresseswithoutregardforwhetheritreceiveda
requestwithaSIPSRequest-URI.Ifaredirectserverisaccessing
thelocationservice,itisuptotheentitythatprocessesthe
Contactheaderfieldofaredirectiontodeterminetheproprietyof
thecontactaddresses.
EnsuringthatTLSwillbeusedforalloftherequestsegmentsupto
thetargetdomainissomewhatcomplex.Itispossiblethat
cryptographicallyauthenticatedproxyserversalongthewaythatare
non-compliantorcompromisedmaychoosetodisregardtheforwarding
rulesassociatedwithSIPS(andthegeneralforwardingrulesin
Section16.6).Suchmaliciousintermediariescould,forexample,
retargetarequestfromaSIPSURItoaSIPURIinanattemptto
downgradesecurity.
Alternatively,anintermediarymightlegitimatelyretargetarequest
fromaSIPtoaSIPSURI.RecipientsofarequestwhoseRequest-URI
usestheSIPSURIschemethuscannotassumeonthebasisofthe
Request-URIalonethatSIPSwasusedfortheentirerequestpath
(fromtheclientonwards).
Toaddresstheseconcerns,itisRECOMMENDEDthatrecipientsofa
requestwhoseRequest-URIcontainsaSIPorSIPSURIinspecttheTo
headerfieldvaluetoseeifitcontainsaSIPSURI(thoughnotethat
itdoesnotconstituteabreachofsecurityifthisURIhasthesame
schemebutisnotequivalenttotheURIintheToheaderfield).
AlthoughclientsmaychoosetopopulatetheRequest-URIandToheader
fieldofarequestdifferently,whenSIPSisusedthisdisparity
couldbeinterpretedasapossiblesecurityviolation,andthe
requestcouldconsequentlyberejectedbyitsrecipient.Recipients
MAYalsoinspecttheViaheaderchaininordertodouble-check
whetherornotTLSwasusedfortheentirerequestpathuntilthe
localadministrativedomainwasreached.S/MIMEmayalsobeusedby
theoriginatingUACtohelpensurethattheoriginalformoftheTo
headerfieldiscarriedend-to-end.
IftheUAShasreasontobelievethattheschemeoftheRequest-URI
hasbeenimproperlymodifiedintransit,theUASHOULDnotifyits
userofapotentialsecuritybreach.
Rosenberg,et.al.StandardsTrack[Page250]
RFC3261SIP:SessionInitiationProtocolJune2002
Asafurthermeasuretopreventdowngradeattacks,entitiesthat
acceptonlySIPSrequestsMAYalsorefuseconnectionsoninsecure
ports.
EnduserswillundoubtedlydiscernthedifferencebetweenSIPSand
SIPURIs,andtheymaymanuallyedittheminresponsetostimuli.
Thiscaneitherbenefitordegradesecurity.Forexample,ifan
attackercorruptsaDNScache,insertingafakerecordsetthat
effectivelyremovesallSIPSrecordsforaproxyserver,thenany
SIPSrequeststhattraversethisproxyservermayfail.Whenauser,
however,seesthatrepeatedcallstoaSIPSAORarefailing,they
couldonsomedevicesmanuallyconverttheschemefromSIPStoSIP
andretry.Ofcourse,therearesomesafeguardsagainstthis(ifthe
destinationUAistrulyparanoiditcouldrefuseallnon-SIPS
requests),butitisalimitationworthnoting.Onthebrightside,
usersmightalsodivinethat'SIPS'wouldbevalidevenwhentheyare
presentedonlywithaSIPURI.
26.5Privacy
SIPmessagesfrequentlycontainsensitiveinformationabouttheir
senders-notjustwhattheyhavetosay,butwithwhomthey
communicate,whentheycommunicateandforhowlong,andfromwhere
theyparticipateinsessions.Manyapplicationsandtheirusers
requirethatthissortofprivateinformationbehiddenfromany
partiesthatdonotneedtoknowit.
Notethattherearealsolessdirectwaysinwhichprivate
informationcanbedivulged.Ifauserorservicechoosestobe
reachableatanaddressthatisguessablefromtheperson'snameand
organizationalaffiliation(whichdescribesmostaddresses-of-
record),thetraditionalmethodofensuringprivacybyhavingan
unlisted"phonenumber"iscompromised.Auserlocationservicecan
infringeontheprivacyoftherecipientofasessioninvitationby
divulgingtheirspecificwhereaboutstothecaller;animplementation
consequentlySHOULDbeabletorestrict,onaper-userbasis,what
kindoflocationandavailabilityinformationisgivenouttocertain
classesofcallers.Thisisawholeclassofproblemthatis
expectedtobestudiedfurtherinongoingSIPwork.
Insomecases,usersmaywanttoconcealpersonalinformationin
headerfieldsthatconveyidentity.Thiscanapplynotonlytothe
Fromandrelatedheadersrepresentingtheoriginatoroftherequest,
butalsotheTo-itmaynotbeappropriatetoconveytothefinal
destinationaspeed-dialingnickname,oranunexpandedidentifierfor
agroupoftargets,eitherofwhichwouldberemovedfromthe
Request-URIastherequestisrouted,butnotchangedintheTo
Rosenberg,et.al.StandardsTrack[Page251]
RFC3261SIP:SessionInitiationProtocolJune2002
headerfieldifthetwowereinitiallyidentical.ThusitMAYbe
desirableforprivacyreasonstocreateaToheaderfieldthat
differsfromtheRequest-URI.
27IANAConsiderations
Allmethodnames,headerfieldnames,statuscodes,andoptiontags
usedinSIPapplicationsareregisteredwithIANAthrough
instructionsinanIANAConsiderationssectioninanRFC.
ThespecificationinstructstheIANAtocreatefournewsub-
registriesunderhttp://www.iana.org/assignments/sip-parameters:
OptionTags,WarningCodes(warn-codes),MethodsandResponseCodes,
addedtothesub-registryofHeaderFieldsthatisalreadypresent
there.
27.1OptionTags
ThisspecificationestablishestheOptionTagssub-registryunder
http://www.iana.org/assignments/sip-parameters.
OptiontagsareusedinheaderfieldssuchasRequire,Supported,
Proxy-Require,andUnsupportedinsupportofSIPcompatibility
mechanismsforextensions(Section19.2).Theoptiontagitselfisa
stringthatisassociatedwithaparticularSIPoption(thatis,an
extension).ItidentifiestheoptiontoSIPendpoints.
OptiontagsareregisteredbytheIANAwhentheyarepublishedin
standardstrackRFCs.TheIANAConsiderationssectionoftheRFC
mustincludethefollowinginformation,whichappearsintheIANA
registryalongwiththeRFCnumberofthepublication.
oNameoftheoptiontag.ThenameMAYbeofanylength,but
SHOULDbenomorethantwentycharacterslong.ThenameMUST
consistofalphanum(Section25)charactersonly.
oDescriptivetextthatdescribestheextension.
27.2Warn-Codes
ThisspecificationestablishestheWarn-codessub-registryunder
http://www.iana.org/assignments/sip-parametersandinitiatesits
populationwiththewarn-codeslistedinSection20.43.Additional
warn-codesareregisteredbyRFCpublication.
Rosenberg,et.al.StandardsTrack[Page252]
RFC3261SIP:SessionInitiationProtocolJune2002
Thedescriptivetextforthetableofwarn-codesis:
Warningcodesprovideinformationsupplementaltothestatuscodein
SIPresponsemessageswhenthefailureofthetransactionresults
fromaSessionDescriptionProtocol(SDP)(RFC2327[1])problem.
The"warn-code"consistsofthreedigits.Afirstdigitof"3"
indicateswarningsspecifictoSIP.Untilafuturespecification
describesusesofwarn-codesotherthan3xx,only3xxwarn-codesmay
beregistered.
Warnings300through329arereservedforindicatingproblemswith
keywordsinthesessiondescription,330through339arewarnings
relatedtobasicnetworkservicesrequestedinthesession
description,370through379arewarningsrelatedtoquantitativeQoS
parametersrequestedinthesessiondescription,and390through399
aremiscellaneouswarningsthatdonotfallintooneoftheabove
categories.
27.3HeaderFieldNames
ThisobsoletestheIANAinstructionsabouttheheadersub-registry
underhttp://www.iana.org/assignments/sip-parameters.
ThefollowinginformationneedstobeprovidedinanRFCpublication
inordertoregisteranewheaderfieldname:
oTheRFCnumberinwhichtheheaderisregistered;
othenameoftheheaderfieldbeingregistered;
oacompactformversionforthatheaderfield,ifoneis
defined;
SomecommonandwidelyusedheaderfieldsMAYbeassignedone-letter
compactforms(Section7.3.3).Compactformscanonlybeassigned
afterSIPworkinggroupreview,followedbyRFCpublication.
27.4MethodandResponseCodes
ThisspecificationestablishestheMethodandResponse-Codesub-
registriesunderhttp://www.iana.org/assignments/sip-parametersand
initiatestheirpopulationasfollows.TheinitialMethodstableis:
Rosenberg,et.al.StandardsTrack[Page253]
RFC3261SIP:SessionInitiationProtocolJune2002
INVITE[RFC3261]
ACK[RFC3261]
BYE[RFC3261]
CANCEL[RFC3261]
REGISTER[RFC3261]
OPTIONS[RFC3261]
INFO[RFC2976]
TheresponsecodetableisinitiallypopulatedfromSection21,the
portionslabeledInformational,Success,Redirection,Client-Error,
Server-Error,andGlobal-Failure.Thetablehasthefollowing
format:
Type(e.g.,Informational)
NumberDefaultReasonPhrase[RFC3261]
ThefollowinginformationneedstobeprovidedinanRFCpublication
inordertoregisteranewresponsecodeormethod:
oTheRFCnumberinwhichthemethodorresponsecodeis
registered;
othenumberoftheresponsecodeornameofthemethodbeing
registered;
othedefaultreasonphraseforthatresponsecode,if
applicable;
27.5The"message/sip"MIMEtype.
Thisdocumentregistersthe"message/sip"MIMEmediatypeinorderto
allowSIPmessagestobetunneledasbodieswithinSIP,primarilyfor
end-to-endsecuritypurposes.Thismediatypeisdefinedbythe
followinginformation:
Mediatypename:message
Mediasubtypename:sip
Requiredparameters:none
Optionalparameters:version
version:TheSIP-Versionnumberoftheenclosedmessage(e.g.,
"2.0").Ifnotpresent,theversiondefaultsto"2.0".
Encodingscheme:SIPmessagesconsistofan8-bitheader
optionallyfollowedbyabinaryMIMEdataobject.Assuch,SIP
messagesmustbetreatedasbinary.Undernormalcircumstances
SIPmessagesaretransportedoverbinary-capabletransports,no
specialencodingsareneeded.
Rosenberg,et.al.StandardsTrack[Page254]
RFC3261SIP:SessionInitiationProtocolJune2002
Securityconsiderations:seebelow
Motivationandexamplesofthisusageasasecuritymechanism
inconcertwithS/MIMEaregivenin23.4.
27.6NewContent-DispositionParameterRegistrations
ThisdocumentalsoregistersfournewContent-Dispositionheader
"disposition-types":alert,icon,sessionandrender.Theauthors
requestthatthesevaluesberecordedintheIANAregistryfor
Content-Dispositions.
Descriptionsofthese"disposition-types",includingmotivationand
examples,aregiveninSection20.11.
ShortdescriptionssuitablefortheIANAregistryare:
alertthebodyisacustomringtonetoalerttheuser
iconthebodyisdisplayedasanicontotheuser
renderthebodyshouldbedisplayedtotheuser
sessionthebodydescribesacommunicationssession,for
example,asRFC2327SDPbody
28ChangesFromRFC2543
ThisRFCrevisesRFC2543.Itismostlybackwardscompatiblewith
RFC2543.Thechangesdescribedherefixmanyerrorsdiscoveredin
RFC2543andprovideinformationonscenariosnotdetailedinRFC
2543.Theprotocolhasbeenpresentedinamorecleanlylayered
modelhere.
Webreakthedifferencesintofunctionalbehaviorthatisa
substantialchangefromRFC2543,whichhasimpacton
interoperabilityorcorrectoperationinsomecases,andfunctional
behaviorthatisdifferentfromRFC2543butnotapotentialsource
ofinteroperabilityproblems.Therehavebeencountless
clarificationsaswell,whicharenotdocumentedhere.
28.1MajorFunctionalChanges
oWhenaUACwishestoterminateacallbeforeithasbeenanswered,
itsendsCANCEL.IftheoriginalINVITEstillreturnsa2xx,the
UACthensendsBYE.BYEcanonlybesentonanexistingcallleg
(nowcalledadialoginthisRFC),whereasitcouldbesentatany
timeinRFC2543.
oTheSIPBNFwasconvertedtobeRFC2234compliant.
Rosenberg,et.al.StandardsTrack[Page255]
RFC3261SIP:SessionInitiationProtocolJune2002
oSIPURLBNFwasmademoregeneral,allowingagreatersetof
charactersintheuserpart.Furthermore,comparisonruleswere
simplifiedtobeprimarilycase-insensitive,anddetailedhandling
ofcomparisoninthepresenceofparameterswasdescribed.The
mostsubstantialchangeisthataURIwithaparameterwiththe
defaultvaluedoesnotmatchaURIwithoutthatparameter.
oRemovedViahiding.Ithadserioustrustissues,sinceitrelied
onthenexthoptoperformtheobfuscationprocess.Instead,Via
hidingcanbedoneasalocalimplementationchoiceinstateful
proxies,andthusisnolongerdocumented.
oInRFC2543,CANCELandINVITEtransactionswereintermingled.
Theyareseparatednow.WhenausersendsanINVITEandthena
CANCEL,theINVITEtransactionstillterminatesnormally.AUAS
needstorespondtotheoriginalINVITErequestwitha487
response.
oSimilarly,CANCELandBYEtransactionswereintermingled;RFC2543
allowedtheUASnottosendaresponsetoINVITEwhenaBYEwas
received.Thatisdisallowedhere.TheoriginalINVITEneedsa
response.
oInRFC2543,UAsneededtosupportonlyUDP.InthisRFC,UAs
needtosupportbothUDPandTCP.
oInRFC2543,aforkingproxyonlypasseduponechallengefrom
downstreamelementsintheeventofmultiplechallenges.Inthis
RFC,proxiesaresupposedtocollectallchallengesandplacethem
intotheforwardedresponse.
oInDigestcredentials,theURIneedstobequoted;thisisunclear
fromRFC2617andRFC2069whicharebothinconsistentonit.
oSDPprocessinghasbeensplitoffintoaseparatespecification
[13],andmorefullyspecifiedasaformaloffer/answerexchange
processthatiseffectivelytunneledthroughSIP.SDPisallowed
inINVITE/200or200/ACKforbaselineSIPimplementations;RFC
2543alludedtotheabilitytouseitinINVITE,200,andACKina
singletransaction,butthiswasnotwellspecified.Morecomplex
SDPusagesareallowedinextensions.
Rosenberg,et.al.StandardsTrack[Page256]
RFC3261SIP:SessionInitiationProtocolJune2002
oAddedfullsupportforIPv6inURIsandintheViaheaderfield.
SupportforIPv6inViahasrequiredthatitsheaderfield
parametersallowthesquarebracketandcoloncharacters.These
characterswerepreviouslynotpermitted.Intheory,thiscould
causeinteropproblemswitholderimplementations.However,we
haveobservedthatmostimplementationsacceptanynon-control
ASCIIcharacterintheseparameters.
oDNSSRVprocedureisnowdocumentedinaseparatespecification
[4].ThisprocedureusesbothSRVandNAPTRresourcerecordsand
nolongercombinesdatafromacrossSRVrecordsasdescribedin
RFC2543.
oLoopdetectionhasbeenmadeoptional,supplantedbyamandatory
usageofMax-Forwards.TheloopdetectionprocedureinRFC2543
hadaseriousbugwhichwouldreport"spirals"asanerror
conditionwhenitwasnot.Theoptionalloopdetectionprocedure
ismorefullyandcorrectlyspecifiedhere.
oUsageoftagsisnowmandatory(theywereoptionalinRFC2543),
astheyarenowthefundamentalbuildingblocksofdialog
identification.
oAddedtheSupportedheaderfield,allowingforclientstoindicate
whatextensionsaresupportedtoaserver,whichcanapplythose
extensionstotheresponse,andindicatetheirusagewitha
Requireintheresponse.
oExtensionparametersweremissingfromtheBNFforseveralheader
fields,andtheyhavebeenadded.
oHandlingofRouteandRecord-Routeconstructionwasvery
underspecifiedinRFC2543,andalsonottherightapproach.It
hasbeensubstantiallyreworkedinthisspecification(andmade
vastlysimpler),andthisisarguablythelargestchange.
Backwardscompatibilityisstillprovidedfordeploymentsthatdo
notuse"pre-loadedroutes",wheretheinitialrequesthasaset
ofRouteheaderfieldvaluesobtainedinsomewayoutsideof
Record-Route.Inthosesituations,thenewmechanismisnot
interoperable.
oInRFC2543,linesinamessagecouldbeterminatedwithCR,LF,
orCRLF.ThisspecificationonlyallowsCRLF.
Rosenberg,et.al.StandardsTrack[Page257]
RFC3261SIP:SessionInitiationProtocolJune2002
oUsageofRouteinCANCELandACKwasnotwelldefinedinRFC2543.
Itisnowwellspecified;ifarequesthadaRouteheaderfield,
itsCANCELorACKforanon-2xxresponsetotherequestneedto
carrythesameRouteheaderfieldvalues.ACKsfor2xxresponses
usetheRoutevalueslearnedfromtheRecord-Routeofthe2xx
responses.
oRFC2543allowedmultiplerequestsinasingleUDPpacket.This
usagehasbeenremoved.
oUsageofabsolutetimeintheExpiresheaderfieldandparameter
hasbeenremoved.Itcausedinteroperabilityproblemsinelements
thatwerenottimesynchronized,acommonoccurrence.Relative
timesareusedinstead.
oThebranchparameteroftheViaheaderfieldvalueisnow
mandatoryforallelementstouse.Itnowplaystheroleofa
uniquetransactionidentifier.Thisavoidsthecomplexandbug-
ladentransactionidentificationrulesfromRFC2543.Amagic
cookieisusedintheparametervaluetodetermineiftheprevious
hophasmadetheparametergloballyunique,andcomparisonfalls
backtotheoldruleswhenitisnotpresent.Thus,
interoperabilityisassured.
oInRFC2543,closureofaTCPconnectionwasmadeequivalenttoa
CANCEL.Thiswasnearlyimpossibletoimplement(andwrong)for
TCPconnectionsbetweenproxies.Thishasbeeneliminated,so
thatthereisnocouplingbetweenTCPconnectionstateandSIP
processing.
oRFC2543wassilentonwhetheraUAcouldinitiateanew
transactiontoapeerwhileanotherwasinprogress.Thatisnow
specifiedhere.Itisallowedfornon-INVITErequests,disallowed
forINVITE.
oPGPwasremoved.Itwasnotsufficientlyspecified,andnot
compatiblewiththemorecompletePGPMIME.Itwasreplacedwith
S/MIME.
oAddedthe"sips"URIschemeforend-to-endTLS.Thisschemeis
notbackwardscompatiblewithRFC2543.Existingelementsthat
receivearequestwithaSIPSURIschemeintheRequest-URIwill
likelyrejecttherequest.Thisisactuallyafeature;itensures
thatacalltoaSIPSURIisonlydeliveredifallpathhopscan
besecured.
Rosenberg,et.al.StandardsTrack[Page258]
RFC3261SIP:SessionInitiationProtocolJune2002
oAdditionalsecurityfeatureswereaddedwithTLS,andtheseare
describedinamuchlargerandcompletesecurityconsiderations
section.
oInRFC2543,aproxywasnotrequiredtoforwardprovisional
responsesfrom101to199upstream.ThiswaschangedtoMUST.
Thisisimportant,sincemanysubsequentfeaturesdependon
deliveryofallprovisionalresponsesfrom101to199.
oLittlewassaidaboutthe503responsecodeinRFC2543.Ithas
sincefoundsubstantialuseinindicatingfailureoroverload
conditionsinproxies.Thisrequiressomewhatspecialtreatment.
Specifically,receiptofa503shouldtriggeranattemptto
contactthenextelementintheresultofaDNSSRVlookup.Also,
503responseisonlyforwardedupstreambyaproxyundercertain
conditions.
oRFC2543defined,butdidnosufficientlyspecify,amechanismfor
UAauthenticationofaserver.Thathasbeenremoved.Instead,
themutualauthenticationproceduresofRFC2617areallowed.
oAUAcannotsendaBYEforacalluntilithasreceivedanACKfor
theinitialINVITE.ThiswasallowedinRFC2543butleadstoa
potentialracecondition.
oAUAorproxycannotsendCANCELforatransactionuntilitgetsa
provisionalresponsefortherequest.ThiswasallowedinRFC
2543butleadstopotentialraceconditions.
oTheactionparameterinregistrationshasbeendeprecated.Itwas
insufficientforanyusefulservices,andcausedconflictswhen
applicationprocessingwasappliedinproxies.
oRFC2543hadanumberofspecialcasesformulticast.For
example,certainresponsesweresuppressed,timerswereadjusted,
andsoon.Multicastnowplaysamorelimitedrole,andthe
protocoloperationisunaffectedbyusageofmulticastasopposed
tounicast.Thelimitationsasaresultofthataredocumented.
oBasicauthenticationhasbeenremovedentirelyanditsusage
forbidden.
Rosenberg,et.al.StandardsTrack[Page259]
RFC3261SIP:SessionInitiationProtocolJune2002
oProxiesnolongerforwarda6xximmediatelyonreceivingit.
Instead,theyCANCELpendingbranchesimmediately.Thisavoidsa
potentialraceconditionthatwouldresultinaUACgettinga6xx
followedbya2xx.Inallcasesexceptthisracecondition,the
resultwillbethesame-the6xxisforwardedupstream.
oRFC2543didnotaddresstheproblemofrequestmerging.This
occurswhenarequestforksataproxyandlaterrejoinsatan
element.HandlingofmergingisdoneonlyataUA,andprocedures
aredefinedforrejectingallbutthefirstrequest.
28.2MinorFunctionalChanges
oAddedtheAlert-Info,Error-Info,andCall-Infoheaderfieldsfor
optionalcontentpresentationtousers.
oAddedtheContent-Language,Content-DispositionandMIME-Version
headerfields.
oAddeda"glarehandling"mechanismtodealwiththecasewhere
bothpartiessendeachotherare-INVITEsimultaneously.Ituses
thenew491(RequestPending)errorcode.
oAddedtheIn-Reply-ToandReply-Toheaderfieldsforsupporting
thereturnofmissedcallsormessagesatalatertime.
oAddedTLSandSCTPasvalidSIPtransports.
oTherewereavarietyofmechanismsdescribedforhandlingfailures
atanytimeduringacall;thosearenowgenerallyunified.BYE
issenttoterminate.
oRFC2543mandatedretransmissionofINVITEresponsesoverTCP,but
noteditwasreallyonlyneededfor2xx.Thatwasanartifactof
insufficientprotocollayering.Withamorecoherenttransaction
layerdefinedhere,thatisnolongerneeded.Only2xxresponses
toINVITEsareretransmittedoverTCP.
oClientandservertransactionmachinesarenowdrivenbasedon
timeoutsratherthanretransmitcounts.Thisallowsthestate
machinestobeproperlyspecifiedforTCPandUDP.
oTheDateheaderfieldisusedinREGISTERresponsestoprovidea
simplemeansforauto-configurationofdatesinuseragents.
oAllowedaregistrartorejectregistrationswithexpirationsthat
aretooshortinduration.Definedthe423responsecodeandthe
Min-Expiresforthispurpose.
Rosenberg,et.al.StandardsTrack[Page260]
RFC3261SIP:SessionInitiationProtocolJune2002
29NormativeReferences
[1]Handley,M.andV.Jacobson,"SDP:SessionDescription
Protocol",RFC2327,April1998.
[2]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.
[3]Resnick,P.,"InternetMessageFormat",RFC2822,April2001.
[4]Rosenberg,J.andH.Schulzrinne,"SIP:LocatingSIPServers",
RFC3263,June2002.
[5]Berners-Lee,T.,Fielding,R.andL.Masinter,"UniformResource
Identifiers(URI):GenericSyntax",RFC2396,August1998.
[6]Chown,P.,"AdvancedEncryptionStandard(AES)Ciphersuitesfor
TransportLayerSecurity(TLS)",RFC3268,June2002.
[7]Yergeau,F.,"UTF-8,atransformationformatofISO10646",RFC
2279,January1998.
[8]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,
Leach,P.andT.Berners-Lee,"HypertextTransferProtocol--
HTTP/1.1",RFC2616,June1999.
[9]Vaha-Sipila,A.,"URLsforTelephoneCalls",RFC2806,April
2000.
[10]Crocker,D.andP.Overell,"AugmentedBNFforSyntax
Specifications:ABNF",RFC2234,November1997.
[11]Freed,F.andN.Borenstein,"MultipurposeInternetMail
Extensions(MIME)PartTwo:MediaTypes",RFC2046,November
1996.
[12]Eastlake,D.,Crocker,S.andJ.Schiller,"Randomness
RecommendationsforSecurity",RFC1750,December1994.
[13]Rosenberg,J.andH.Schulzrinne,"AnOffer/AnswerModelwith
SDP",RFC3264,June2002.
[14]Postel,J.,"UserDatagramProtocol",STD6,RFC768,August
1980.
[15]Postel,J.,"DoDStandardTransmissionControlProtocol",RFC
761,January1980.
Rosenberg,et.al.StandardsTrack[Page261]
RFC3261SIP:SessionInitiationProtocolJune2002
[16]Stewart,R.,Xie,Q.,Morneault,K.,Sharp,C.,Schwarzbauer,
H.,Taylor,T.,Rytina,I.,Kalla,M.,Zhang,L.andV.Paxson,
"StreamControlTransmissionProtocol",RFC2960,October2000.
[17]Franks,J.,Hallam-Baker,P.,Hostetler,J.,Lawrence,S.,
Leach,P.,Luotonen,A.andL.Stewart,"HTTPauthentication:
BasicandDigestAccessAuthentication",RFC2617,June1999.
[18]Troost,R.,Dorner,S.andK.Moore,"CommunicatingPresentation
InformationinInternetMessages:TheContent-DispositionHeader
Field",RFC2183,August1997.
[19]Zimmerer,E.,Peterson,J.,Vemuri,A.,Ong,L.,Audet,F.,
Watson,M.andM.Zonoun,"MIMEmediatypesforISUPandQSIG
Objects",RFC3204,December2001.
[20]Braden,R.,"RequirementsforInternetHosts-Applicationand
Support",STD3,RFC1123,October1989.
[21]Alvestrand,H.,"IETFPolicyonCharacterSetsandLanguages",
BCP18,RFC2277,January1998.
[22]Galvin,J.,Murphy,S.,Crocker,S.andN.Freed,"Security
MultipartsforMIME:Multipart/SignedandMultipart/Encrypted",
RFC1847,October1995.
[23]Housley,R.,"CryptographicMessageSyntax",RFC2630,June
1999.
[24]RamsdellB.,"S/MIMEVersion3MessageSpecification",RFC2633,
June1999.
[25]Dierks,T.andC.Allen,"TheTLSProtocolVersion1.0",RFC
2246,January1999.
[26]Kent,S.andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.
30InformativeReferences
[27]R.Pandya,"Emergingmobileandpersonalcommunicationsystems,"
IEEECommunicationsMagazine,Vol.33,pp.44--52,June1995.
[28]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,
"RTP:ATransportProtocolforReal-TimeApplications",RFC
1889,January1996.
Rosenberg,et.al.StandardsTrack[Page262]
RFC3261SIP:SessionInitiationProtocolJune2002
[29]Schulzrinne,H.,Rao,R.andR.Lanphier,"RealTimeStreaming
Protocol(RTSP)",RFC2326,April1998.
[30]Cuervo,F.,Greene,N.,Rayhan,A.,Huitema,C.,Rosen,B.and
J.Segers,"MegacoProtocolVersion1.0",RFC3015,November
2000.
[31]Handley,M.,Schulzrinne,H.,Schooler,E.andJ.Rosenberg,
"SIP:SessionInitiationProtocol",RFC2543,March1999.
[32]Hoffman,P.,Masinter,L.andJ.Zawinski,"ThemailtoURL
scheme",RFC2368,July1998.
[33]E.M.Schooler,"Amulticastuserdirectoryservicefor
synchronousrendezvous,"Master'sThesisCS-TR-96-18,Department
ofComputerScience,CaliforniaInstituteofTechnology,
Pasadena,California,Aug.1996.
[34]Donovan,S.,"TheSIPINFOMethod",RFC2976,October2000.
[35]Rivest,R.,"TheMD5Message-DigestAlgorithm",RFC1321,April
1992.
[36]Dawson,F.andT.Howes,"vCardMIMEDirectoryProfile",RFC
2426,September1998.
[37]Good,G.,"TheLDAPDataInterchangeFormat(LDIF)-Technical
Specification",RFC2849,June2000.
[38]Palme,J.,"CommonInternetMessageHeaders",RFC2076,
February1997.
[39]Franks,J.,Hallam-Baker,P.,Hostetler,J.,Leach,P.,
Luotonen,A.,Sink,E.andL.Stewart,"AnExtensiontoHTTP:
DigestAccessAuthentication",RFC2069,January1997.
[40]Johnston,A.,Donovan,S.,Sparks,R.,Cunningham,C.,Willis,
D.,Rosenberg,J.,Summers,K.andH.Schulzrinne,"SIPCall
FlowExamples",WorkinProgress.
[41]E.M.Schooler,"Casestudy:multimediaconferencecontrolina
packet-switchedteleconferencingsystem,"Journalof
Internetworking:ResearchandExperience,Vol.4,pp.99--120,
June1993.ISIreprintseriesISI/RS-93-359.
Rosenberg,et.al.StandardsTrack[Page263]
RFC3261SIP:SessionInitiationProtocolJune2002
[42]H.Schulzrinne,"Personalmobilityformultimediaservicesin
theInternet,"inEuropeanWorkshoponInteractiveDistributed
MultimediaSystemsandServices(IDMS),(Berlin,Germany),Mar.
1996.
[43]Floyd,S.,"CongestionControlPrinciples",RFC2914,September
2000.
Rosenberg,et.al.StandardsTrack[Page264]
RFC3261SIP:SessionInitiationProtocolJune2002
ATableofTimerValues
Table4summarizesthemeaninganddefaultsofthevarioustimers
usedbythisspecification.
TimerValueSectionMeaning
----------------------------------------------------------------------
T1500msdefaultSection17.1.1.1RTTEstimate
T24sSection17.1.2.2Themaximumretransmit
intervalfornon-INVITE
requestsandINVITE
responses
T45sSection17.1.2.2Maximumdurationa
messagewill
remaininthenetwork
TimerAinitiallyT1Section17.1.1.2INVITErequestretransmit
interval,forUDPonly
TimerB64*T1Section17.1.1.2INVITEtransaction
timeouttimer
TimerC>3minSection16.6proxyINVITEtransaction
bullet11timeout
TimerD>32sforUDPSection17.1.1.2Waittimeforresponse
0sforTCP/SCTPretransmits
TimerEinitiallyT1Section17.1.2.2non-INVITErequest
retransmitinterval,
UDPonly
TimerF64*T1Section17.1.2.2non-INVITEtransaction
timeouttimer
TimerGinitiallyT1Section17.2.1INVITEresponse
retransmitinterval
TimerH64*T1Section17.2.1Waittimefor
ACKreceipt
TimerIT4forUDPSection17.2.1Waittimefor
0sforTCP/SCTPACKretransmits
TimerJ64*T1forUDPSection17.2.2Waittimefor
0sforTCP/SCTPnon-INVITErequest
retransmits
TimerKT4forUDPSection17.1.2.2Waittimefor
0sforTCP/SCTPresponseretransmits
Table4:Summaryoftimers
Rosenberg,et.al.StandardsTrack[Page265]
RFC3261SIP:SessionInitiationProtocolJune2002
Acknowledgments
WewishtothankthemembersoftheIETFMMUSICandSIPWGsfortheir
commentsandsuggestions.DetailedcommentswereprovidedbyOfir
Arkin,BrianBidulock,JimBuller,NeilDeason,DaveDevanathan,
KeithDrage,BillFenner,CedricFluckiger,YaronGoland,John
Hearty,BernieHoeneisen,JoHornsby,PhilHoffer,ChristianHuitema,
HishamKhartabil,JeanJervis,GadiKarmi,PeterKjellerstedt,Anders
Kristensen,JonathanLennox,GethinLiddell,AllisonMankin,William
Marshall,RohanMahy,KeithMoore,VernPaxson,BobPenfield,Moshe
J.Sambol,ChipSharp,IgorSlepchin,EricTremblay,andRick
Workman.
BrianRosenprovidedthecompiledBNF.
JeanMahoneyprovidedtechnicalwritingassistance.
Thisworkisbased,interalia,on[41,42].
Rosenberg,et.al.StandardsTrack[Page266]
RFC3261SIP:SessionInitiationProtocolJune2002
Authors'Addresses
Authorsaddressesarelistedalphabeticallyfortheeditors,the
writers,andthentheoriginalauthorsofRFC2543.Alllisted
authorsactivelycontributedlargeamountsoftexttothisdocument.
JonathanRosenberg
dynamicsoft
72EagleRockAve
EastHanover,NJ07936
USA
EMail:[email protected]
HenningSchulzrinne
Dept.ofComputerScience
ColumbiaUniversity
1214AmsterdamAvenue
NewYork,NY10027
USA
EMail:[email protected]
GonzaloCamarillo
Ericsson
AdvancedSignallingResearchLab.
FIN-02420Jorvas
Finland
EMail:[email protected]
AlanJohnston
WorldCom
100South4thStreet
St.Louis,MO63102
USA
EMail:[email protected]
Rosenberg,et.al.StandardsTrack[Page267]
RFC3261SIP:SessionInitiationProtocolJune2002
JonPeterson
NeuStar,Inc
1800SutterStreet,Suite570
Concord,CA94520
USA
EMail:[email protected]
RobertSparks
dynamicsoft,Inc.
5100TennysonParkway
Suite1200
Plano,Texas75024
USA
EMail:[email protected]
MarkHandley
InternationalComputerScienceInstitute
1947CenterSt,Suite600
Berkeley,CA94704
USA
EMail:[email protected]
EveSchooler
AT&TLabs-Research
75WillowRoad
MenloPark,CA94025
USA
EMail:[email protected]
Rosenberg,et.al.StandardsTrack[Page268]
RFC3261SIP:SessionInitiationProtocolJune2002
FullCopyrightStatement
Copyright(C)TheInternetSociety(2002).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
Acknowledgement
FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.
Rosenberg,et.al.StandardsTrack[Page269]
