SIP Protocol Rfc3261

1/5/2015 https://www.ietf.org/rfc/rfc3261.
txt
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
applicationlayercontrol(signaling)protocolforcreating,
modifying,andterminatingsessionswithoneormoreparticipants.
ThesesessionsincludeInternettelephonecalls,multimedia
distribution,andmultimediaconferences.
SIPinvitationsusedtocreatesessionscarrysessiondescriptions
thatallowparticipantstoagreeonasetofcompatiblemediatypes.
SIPmakesuseofelementscalledproxyserverstohelprouterequests
totheuser'scurrentlocation,authenticateandauthorizeusersfor
services,implementprovidercallroutingpolicies,andprovide
featurestousers.SIPalsoprovidesaregistrationfunctionthat
allowsuserstouploadtheircurrentlocationsforusebyproxy
servers.SIPrunsontopofseveraldifferenttransportprotocols.
https://www.ietf.org/rfc/rfc3261.txt 1/265
1/5/2015 https://www.ietf.org/rfc/rfc3261.txt
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.1RequestURI.........................................35
8.1.1.2To..................................................36
8.1.1.3From................................................37
8.1.1.4CallID.............................................37
8.1.1.5CSeq................................................38
8.1.1.6MaxForwards........................................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.1ToandRequestURI..................................46
8.2.2.2MergedRequests.....................................47
8.2.2.3Require.............................................47
8.2.3ContentProcessing..................................48
8.2.4ApplyingExtensions.................................49
8.2.5ProcessingtheRequest..............................49
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
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.2TraversingaStrictRoutingProxy...................120
16.12.1.3RewritingRecordRouteHeaderFieldValues..........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.2NonINVITEClientTransaction.......................130
17.1.2.1OverviewofthenonINVITETransaction..............130
17.1.2.2FormalDescription..................................131
17.1.3MatchingResponsestoClientTransactions...........132
17.1.4HandlingTransportErrors...........................133
17.2ServerTransaction..................................134
17.2.1INVITEServerTransaction...........................134
17.2.2NonINVITEServerTransaction.......................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
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.2AcceptEncoding.....................................163
20.3AcceptLanguage.....................................164
20.4AlertInfo..........................................164
20.5Allow...............................................165
20.6AuthenticationInfo.................................165
20.7Authorization.......................................165
20.8CallID.............................................166
20.9CallInfo...........................................166
20.10Contact.............................................167
20.11ContentDisposition.................................168
20.12ContentEncoding....................................169
20.13ContentLanguage....................................169
20.14ContentLength......................................169
20.15ContentType........................................170
20.16CSeq................................................170
20.17Date................................................170
20.18ErrorInfo..........................................171
20.19Expires.............................................171
20.20From................................................172
20.21InReplyTo.........................................172
20.22MaxForwards........................................173
20.23MinExpires.........................................173
20.24MIMEVersion........................................173
20.25Organization........................................174
20.26Priority............................................174
20.27ProxyAuthenticate..................................174
20.28ProxyAuthorization.................................175
20.29ProxyRequire.......................................175
20.30RecordRoute........................................175
20.31ReplyTo............................................176
20.32Require.............................................176
20.33RetryAfter.........................................176
20.34Route...............................................177
20.35Server..............................................177
20.36Subject.............................................177
20.37Supported...........................................178
20.38Timestamp...........................................178
20.39To..................................................178
20.40Unsupported.........................................179
20.41UserAgent..........................................179
20.42Via.................................................179
20.43Warning.............................................180
20.44WWWAuthenticate....................................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.12414RequestURITooLong............................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
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.5504ServerTimeout.................................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.2UsertoUserAuthentication.........................195
22.3ProxytoUserAuthentication........................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
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.3PeertoPeerRequests...............................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.2WarnCodes..........................................252
27.3HeaderFieldNames..................................253
27.4MethodandResponseCodes...........................253
27.5The"message/sip"MIMEtype........................254
27.6NewContentDispositionParameterRegistrations.....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
differentmediasometimessimultaneously.Numerousprotocolshave
beenauthoredthatcarryvariousformsofrealtimemultimedia
sessiondatasuchasvoice,video,ortextmessages.TheSession
InitiationProtocol(SIP)worksinconcertwiththeseprotocolsby
enablingInternetendpoints(calleduseragents)todiscoverone
anotherandtoagreeonacharacterizationofasessiontheywould
liketoshare.Forlocatingprospectivesessionparticipants,and
forotherfunctions,SIPenablesthecreationofaninfrastructureof
networkhosts(calledproxyservers)towhichuseragentscansend
registrations,invitationstosessions,andotherrequests.SIPis
anagile,generalpurposetoolforcreating,modifying,and
terminatingsessionsthatworksindependentlyofunderlyingtransport
protocolsandwithoutdependencyonthetypeofsessionthatisbeing
established.
2OverviewofSIPFunctionality
SIPisanapplicationlayercontrolprotocolthatcanestablish,
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
architectureswillincludeprotocolssuchastheRealtimeTransport
Protocol(RTP)(RFC1889[28])fortransportingrealtimedataand
providingQoSfeedback,theRealTimestreamingprotocol(RTSP)(RFC
2326[29])forcontrollingdeliveryofstreamingmedia,theMedia
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,
whichincludedenialofserviceprevention,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.
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:bob@biloxi.com,wherebiloxi.comisthedomainofBob'sSIP
serviceprovider.AlicehasaSIPURIofsip:alice@atlanta.com.
AlicemighthavetypedinBob'sURIorperhapsclickedonahyperlink
oranentryinanaddressbook.SIPalsoprovidesasecureURI,
calledaSIPSURI.Anexamplewouldbesips:bob@biloxi.com.Acall
madetoaSIPSURIguaranteesthatsecure,encryptedtransport
(namelyTLS)isusedtocarryallSIPmessagesfromthecallertothe
domainofthecallee.Fromthere,therequestissentsecurelyto
thecallee,butwithsecuritymechanismsthatdependonthepolicyof
thedomainofthecallee.
SIPisbasedonanHTTPlikerequest/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:
atlanta.com...biloxi.com
.proxyproxy.
..
Alice's....................Bob's
softphoneSIPPhone
||||
|INVITEF1|||
|>|INVITEF2||
|100TryingF3|>|INVITEF4|
|<|100TryingF5|>|
||<|180RingingF6|
||180RingingF7|<|
|180RingingF8|<|200OKF9|
|<|200OKF10|<|
|200OKF11|<||
|<|||
|ACKF12|
|>|
|MediaSession|
|<================================================>|
|BYEF13|
|<|
|200OKF14|
|>|
||
Figure1:SIPsessionsetupexamplewithSIPtrapezoid
INVITEsip:bob@biloxi.comSIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bK776asdhds
MaxForwards:70
To:Bob<sip:bob@biloxi.com>
From:Alice<sip:alice@atlanta.com>tag=1928301774
CallID:a84b4c76e66710@pc33.atlanta.com
CSeq:314159INVITE
Contact:<sip:alice@pc33.atlanta.com>
ContentType:application/sdp
ContentLength:142
(Alice'sSDPnotshown)
Thefirstlineofthetextencodedmessagecontainsthemethodname
(INVITE).Thelinesthatfollowarealistofheaderfields.This
examplecontainsaminimumrequiredset.Theheaderfieldsare
brieflydescribedbelow:
Viacontainstheaddress(pc33.atlanta.com)atwhichAliceis
expectingtoreceiveresponsestothisrequest.Italsocontainsa
branchparameterthatidentifiesthistransaction.
Tocontainsadisplayname(Bob)andaSIPorSIPSURI
(sip:bob@biloxi.com)towardswhichtherequestwasoriginally
directed.DisplaynamesaredescribedinRFC2822[3].
Fromalsocontainsadisplayname(Alice)andaSIPorSIPSURI
(sip:alice@atlanta.com)thatindicatetheoriginatoroftherequest.
Thisheaderfieldalsohasatagparametercontainingarandomstring
(1928301774)thatwasaddedtotheURIbythesoftphone.Itisused
foridentificationpurposes.
CallIDcontainsagloballyuniqueidentifierforthiscall,
generatedbythecombinationofarandomstringandthesoftphone's
hostnameorIPaddress.ThecombinationoftheTotag,Fromtag,
andCallIDcompletelydefinesapeertopeerSIPrelationship
betweenAliceandBobandisreferredtoasadialog.
CSeqorCommandSequencecontainsanintegerandamethodname.The
CSeqnumberisincrementedforeachnewrequestwithinadialogand
isatraditionalsequencenumber.
ContactcontainsaSIPorSIPSURIthatrepresentsadirectrouteto
contactAlice,usuallycomposedofausernameatafullyqualified
domainname(FQDN).WhileanFQDNispreferred,manyendsystemsdo
nothaveregistereddomainnames,soIPaddressesarepermitted.
WhiletheViaheaderfieldtellsotherelementswheretosendthe
response,theContactheaderfieldtellsotherelementswheretosend
futurerequests.
MaxForwardsservestolimitthenumberofhopsarequestcanmakeon
thewaytoitsdestination.Itconsistsofanintegerthatis
decrementedbyoneateachhop.
ContentTypecontainsadescriptionofthemessagebody(notshown).
ContentLengthcontainsanoctet(byte)countofthemessagebody.
ThecompletesetofSIPheaderfieldsisdefinedinSection20.
Thedetailsofthesession,suchasthetypeofmedia,codec,or
samplingrate,arenotdescribedusingSIP.Rather,thebodyofa
SIPmessagecontainsadescriptionofthesession,encodedinsome
otherprotocolformat.OnesuchformatistheSessionDescription
Protocol(SDP)(RFC2327[1]).ThisSDPmessage(notshowninthe
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.ResponsesinSIPuseathreedigit
codefollowedbyadescriptivephrase.Thisresponsecontainsthe
sameTo,From,CallID,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
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,thereisatwophase
exchangeofSDPmessages:AlicesentonetoBob,andBobsentone
backtoAlice.Thistwophaseexchangeprovidesbasicnegotiation
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=z9hG4bKnashds8received=192.0.2.3
Via:SIP/2.0/UDPbigbox3.site3.atlanta.com
branch=z9hG4bK77ef4c2312983.1received=192.0.2.2
Via:SIP/2.0/UDPpc33.atlanta.com
branch=z9hG4bK776asdhdsreceived=192.0.2.1
To:Bob<sip:bob@biloxi.com>tag=a6c85cf
CallID:a84b4c76e66710@pc33.atlanta.com
CSeq:314159INVITE
Contact:<sip:bob@192.0.2.4>
ContentLength:131
(Bob'sSDPnotshown)
Thefirstlineoftheresponsecontainstheresponsecode(200)and
thereasonphrase(OK).Theremaininglinescontainheaderfields.
TheVia,To,From,CallID,andCSeqheaderfieldsarecopiedfrom
theINVITErequest.(TherearethreeViaheaderfieldvaluesone
addedbyAlice'sSIPphone,oneaddedbytheatlanta.comproxy,and
oneaddedbythebiloxi.comproxy.)Bob'sSIPphonehasaddedatag
parametertotheToheaderfield.Thistagwillbeincorporatedby
bothendpointsintothedialogandwillbeincludedinallfuture
requestsandresponsesinthiscall.TheContactheaderfield
containsaURIatwhichBobcanbedirectlyreachedathisSIPphone.
TheContentTypeandContentLengthrefertothemessagebody(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/ACKthreewayhandshakeusedtoestablish
SIPsessions.FulldetailsonsessionsetupareinSection13.
AliceandBob'smediasessionhasnowbegun,andtheysendmedia
packetsusingtheformattowhichtheyagreedintheexchangeofSDP.
Ingeneral,theendtoendmediapacketstakeadifferentpathfrom
theSIPsignalingmessages.
Duringthesession,eitherAliceorBobmaydecidetochangethe
characteristicsofthemediasession.Thisisaccomplishedby
sendingareINVITEcontaininganewmediadescription.Thisre
INVITEreferencestheexistingdialogsothattheotherpartyknows
thatitistomodifyanexistingsessioninsteadofestablishinga
newsession.Theotherpartysendsa200(OK)toacceptthechange.
Therequestorrespondstothe200(OK)withanACK.Iftheother
partydoesnotacceptthechange,hesendsanerrorresponsesuchas
488(NotAcceptableHere),whichalsoreceivesanACK.However,the
failureofthereINVITEdoesnotcausetheexistingcalltofail
thesessioncontinuesusingthepreviouslynegotiated
characteristics.FulldetailsonsessionmodificationareinSection
14.
Attheendofthecall,Bobdisconnects(hangsup)firstand
generatesaBYEmessage.ThisBYEisrouteddirectlytoAlice's
softphone,againbypassingtheproxies.Aliceconfirmsreceiptof
theBYEwitha200(OK)response,whichterminatesthesessionand
theBYEtransaction.NoACKissentanACKisonlysentin
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(duetotheRecordRouteheaderfieldbeingpassedbackin
the200(OK))Alice'ssoftphoneandstoredforthedurationofthe
dialog.Thebiloxi.comproxyserverwouldthenreceiveandproxythe
ACK,BYE,and200(OK)totheBYE.Eachproxycanindependently
decidetoreceivesubsequentmessages,andthosemessageswillpass
throughallproxiesthatelecttoreceiveit.Thiscapabilityis
frequentlyusedforproxiesthatareprovidingmidcallfeatures.
RegistrationisanothercommonoperationinSIP.Registrationisone
waythatthebiloxi.comservercanlearnthecurrentlocationofBob.
Uponinitialization,andatperiodicintervals,Bob'sSIPphonesends
REGISTERmessagestoaserverinthebiloxi.comdomainknownasaSIP
registrar.TheREGISTERmessagesassociateBob'sSIPorSIPSURI
(sip:bob@biloxi.com)withthemachineintowhichheiscurrently
logged(conveyedasaSIPorSIPSURIintheContactheaderfield).
Theregistrarwritesthisassociation,alsocalledabinding,toa
database,calledthelocationservice,whereitcanbeusedbythe
proxyinthebiloxi.comdomain.Often,aregistrarserverfora
domainiscolocatedwiththeproxyforthatdomain.Itisan
importantconceptthatthedistinctionbetweentypesofSIPservers
islogical,notphysical.
Bobisnotlimitedtoregisteringfromasingledevice.Forexample,
bothhisSIPphoneathomeandtheoneintheofficecouldsend
registrations.Thisinformationisstoredtogetherinthelocation
serviceandallowsaproxytoperformvarioustypesofsearchesto
locateBob.Similarly,morethanoneusercanberegisteredona
singledeviceatthesametime.
Thelocationserviceisjustanabstractconcept.Itgenerally
containsinformationthatallowsaproxytoinputaURIandreceivea
setofzeroormoreURIsthattelltheproxywheretosendthe
request.Registrationsareonewaytocreatethisinformation,but
nottheonlyway.Arbitrarymappingfunctionscanbeconfiguredat
thediscretionoftheadministrator.
Finally,itisimportanttonotethatinSIP,registrationisused
forroutingincomingSIPrequestsandhasnoroleinauthorizing
outgoingrequests.Authorizationandauthenticationarehandledin
SIPeitheronarequestbyrequestbasiswithachallenge/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,perhapsevenonatransactionbytransactionbasis.
ThelowestlayerofSIPisitssyntaxandencoding.Itsencodingis
specifiedusinganaugmentedBackusNaurFormgrammar(BNF).The
completeBNFisspecifiedinSection25anoverviewofaSIP
message'sstructurecanbefoundinSection7.
Thesecondlayeristhetransportlayer.Itdefineshowaclient
sendsrequestsandreceivesresponsesandhowaserverreceives
requestsandsendsresponsesoverthenetwork.AllSIPelements
containatransportlayer.Thetransportlayerisdescribedin
Section18.
Thethirdlayeristhetransactionlayer.Transactionsarea
fundamentalcomponentofSIP.Atransactionisarequestsentbya
clienttransaction(usingthetransportlayer)toaserver
transaction,alongwithallresponsestothatrequestsentfromthe
servertransactionbacktotheclient.Thetransactionlayerhandles
applicationlayerretransmissions,matchingofresponsestorequests,
andapplicationlayertimeouts.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
ofarequestforaUAS,theygoverntheprocessingofarequestand
generatingaresponse.Sinceregistrationsplayanimportantrolein
SIP,aUASthathandlesaREGISTERisgiventhespecialname
registrar.Section10describesUACandUAScorebehaviorforthe
REGISTERmethod.Section11describesUACandUAScorebehaviorfor
theOPTIONSmethod,usedfordeterminingthecapabilitiesofaUA.
Certainotherrequestsaresentwithinadialog.Adialogisa
peertopeerSIPrelationshipbetweentwouseragentsthatpersists
forsometime.Thedialogfacilitatessequencingofmessagesand
properroutingofrequestsbetweentheuseragents.TheINVITE
methodistheonlywaydefinedinthisspecificationtoestablisha
dialog.WhenaUACsendsarequestthatiswithinthecontextofa
dialog,itfollowsthecommonUACrulesasdiscussedinSection8but
alsotherulesformiddialogrequests.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.
AddressofRecord:Anaddressofrecord(AOR)isaSIPorSIPSURI
thatpointstoadomainwithalocationservicethatcanmap
theURItoanotherURIwheretheusermightbeavailable.
Typically,thelocationserviceispopulatedthrough
registrations.AnAORisfrequentlythoughtofasthe"public
address"oftheuser.
BacktoBackUserAgent:Abacktobackuseragent(B2BUA)isa
logicalentitythatreceivesarequestandprocessesitasa
useragentserver(UAS).Inordertodeterminehowtherequest
shouldbeanswered,itactsasauseragentclient(UAC)and
generatesrequests.Unlikeaproxyserver,itmaintainsdialog
stateandmustparticipateinallrequestssentonthedialogs
ithasestablished.SinceitisaconcatenationofaUACand
UAS,noexplicitdefinitionsareneededforitsbehavior.
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:AdialogisapeertopeerSIPrelationshipbetweentwo
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
givenheaderfieldrowareseparatedbycommas.Someheader
fieldscanonlyhaveasingleheaderfieldvalue,andasa
result,alwaysappearasasingleheaderfieldrow.
HeaderFieldValue:Aheaderfieldvalueisasinglevaluea
headerfieldconsistsofzeroormoreheaderfieldvalues.
HomeDomain:ThedomainprovidingservicetoaSIPuser.
Typically,thisisthedomainpresentintheURIinthe
addressofrecordofaregistration.
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).Itcontainsalistofbindingsofaddressof
recordkeystozeroormorecontactaddresses.Thebindings
canbecreatedandremovedinmanywaysthisspecification
definesaREGISTERmethodthatupdatesthebindings.
Loop:Arequestthatarrivesataproxy,isforwarded,andlater
arrivesbackatthesameproxy.Whenitarrivesthesecond
time,itsRequestURIisidenticaltothefirsttime,andother
headerfieldsthataffectproxyoperationareunchanged,so
thattheproxywouldmakethesameprocessingdecisiononthe
requestitmadethefirsttime.Loopedrequestsareerrors,
andtheproceduresfordetectingthemandhandlingthemare
describedbytheprotocol.
LooseRouting:Aproxyissaidtobelooseroutingifitfollows
theproceduresdefinedinthisspecificationforprocessingof
theRouteheaderfield.Theseproceduresseparatethe
destinationoftherequest(presentintheRequestURI)from
thesetofproxiesthatneedtobevisitedalongtheway
(presentintheRouteheaderfield).Aproxycompliantto
thesemechanismsisalsoknownasalooserouter.
Message:DatasentbetweenSIPelementsaspartoftheprotocol.
SIPmessagesareeitherrequestsorresponses.
Method:Themethodistheprimaryfunctionthatarequestismeant
toinvokeonaserver.Themethodiscarriedintherequest
messageitself.ExamplemethodsareINVITEandBYE.
OutboundProxy:Aproxythatreceivesrequestsfromaclient,even
thoughitmaynotbetheserverresolvedbytheRequestURI.
Typically,aUAismanuallyconfiguredwithanoutboundproxy,
orcanlearnaboutonethroughautoconfigurationprotocols.
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.
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,
throughheaderslikeRecordRoute,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(non1xx)response
sentfromtheservertotheclient.IftherequestisINVITE
andthefinalresponseisanon2xx,thetransactionalso
includesanACKtotheresponse.TheACKfora2xxresponseto
anINVITErequestisaseparatetransaction.
Spiral:AspiralisaSIPrequestthatisroutedtoaproxy,
forwardedonwards,andarrivesonceagainatthatproxy,but
thistimediffersinawaythatwillresultinadifferent
processingdecisionthantheoriginalrequest.Typically,this
meansthattherequest'sRequestURIdiffersfromitsprevious
arrival.Aspiralisnotanerrorcondition,unlikealoop.A
typicalcauseforthisiscallforwarding.Ausercalls
joe@example.com.Theexample.comproxyforwardsittoJoe's
PC,whichinturn,forwardsittobob@example.com.This
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
destroythecontentsoftheRequestURIwhenaRouteheader
fieldwaspresent.Strictroutingbehaviorisnotusedinthis
specification,infavorofalooseroutingbehavior.Proxies
thatperformstrictroutingarealsoknownasstrictrouters.
TargetRefreshRequest:Atargetrefreshrequestsentwithina
dialogisdefinedasarequestthatcanmodifytheremote
targetofthedialog.
TransactionUser(TU):Thelayerofprotocolprocessingthat
residesabovethetransactionlayer.Transactionusersinclude
theUACcore,UAScore,andproxycore.
Upstream:Adirectionofmessageforwardingwithinatransaction
thatreferstothedirectionthatresponsesflowfromtheuser
agentserverbacktotheuseragentclient.
URLencoded:AcharacterstringencodedaccordingtoRFC2396,
Section2.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
definedonatransactionbytransactionbasis.Forexample,theuser
agentinitiatingacallactsasaUACwhensendingtheinitialINVITE
requestandasaUASwhenreceivingaBYErequestfromthecallee.
Similarly,thesamesoftwarecanactasaproxyserverforone
requestandasaredirectserverforthenextrequest.
Proxy,location,andregistrarserversdefinedabovearelogical
entitiesimplementationsMAYcombinethemintoasingleapplication.
7SIPMessages
SIPisatextbasedprotocolandusestheUTF8charset(RFC2279
[7]).
ASIPmessageiseitherarequestfromaclienttoaserver,ora
responsefromaservertoaclient.
BothRequest(section7.1)andResponse(section7.2)messagesuse
thebasicformatofRFC2822[3],eventhoughthesyntaxdiffersin
charactersetandsyntaxspecifics.(SIPallowsheaderfieldsthat
wouldnotbevalidRFC2822headerfields,forexample.)Bothtypes
ofmessagesconsistofastartline,oneormoreheaderfields,an
emptylineindicatingtheendoftheheaderfields,andanoptional
messagebody.
genericmessage=startline
*messageheader
CRLF
[messagebody]
startline=RequestLine/StatusLine
Thestartline,eachmessageheaderline,andtheemptylineMUSTbe
terminatedbyacarriagereturnlinefeedsequence(CRLF).Notethat
theemptylineMUSTbepresentevenifthemessagebodyisnot.
Exceptfortheabovedifferenceincharactersets,muchofSIP's
messageandheaderfieldsyntaxisidenticaltoHTTP/1.1.Rather
thanrepeatingthesyntaxandsemanticshere,weuse[HX.Y]torefer
toSectionX.YofthecurrentHTTP/1.1specification(RFC2616[8]).
However,SIPisnotanextensionofHTTP.
7.1Requests
SIPrequestsaredistinguishedbyhavingaRequestLineforastart
line.ARequestLinecontainsamethodname,aRequestURI,andthe
protocolversionseparatedbyasinglespace(SP)character.
TheRequestLineendswithCRLF.NoCRorLFareallowedexceptin
theendoflineCRLFsequence.Nolinearwhitespace(LWS)isallowed
inanyoftheelements.
RequestLine=MethodSPRequestURISPSIPVersionCRLF
Method:Thisspecificationdefinessixmethods:REGISTERfor
registeringcontactinformation,INVITE,ACK,andCANCELfor
settingupsessions,BYEforterminatingsessions,and
OPTIONSforqueryingserversabouttheircapabilities.SIP
extensions,documentedinstandardstrackRFCs,maydefine
additionalmethods.
RequestURI:TheRequestURIisaSIPorSIPSURIasdescribedin
Section19.1orageneralURI(RFC2396[5]).Itindicates
theuserorservicetowhichthisrequestisbeingaddressed.
TheRequestURIMUSTNOTcontainunescapedspacesorcontrol
charactersandMUSTNOTbeenclosedin"<>".
SIPelementsMAYsupportRequestURIswithschemesotherthan
"sip"and"sips",forexamplethe"tel"URIschemeofRFC
2806[9].SIPelementsMAYtranslatenonSIPURIsusingany
mechanismattheirdisposal,resultinginSIPURI,SIPSURI,
orsomeotherscheme.
SIPVersion:Bothrequestandresponsemessagesincludethe
versionofSIPinuse,andfollow[H3.1](withHTTPreplaced
bySIP,andHTTP/1.1replacedbySIP/2.0)regardingversion
ordering,compliancerequirements,andupgradingofversion
numbers.Tobecompliantwiththisspecification,
applicationssendingSIPmessagesMUSTincludeaSIPVersion
of"SIP/2.0".TheSIPVersionstringiscaseinsensitive,
butimplementationsMUSTsenduppercase.
UnlikeHTTP/1.1,SIPtreatstheversionnumberasaliteral
string.Inpractice,thisshouldmakenodifference.
7.2Responses
SIPresponsesaredistinguishedfromrequestsbyhavingaStatusLine
astheirstartline.AStatusLineconsistsoftheprotocolversion
followedbyanumericStatusCodeanditsassociatedtextualphrase,
witheachelementseparatedbyasingleSPcharacter.
NoCRorLFisallowedexceptinthefinalCRLFsequence.
StatusLine=SIPVersionSPStatusCodeSPReasonPhraseCRLF
TheStatusCodeisa3digitintegerresultcodethatindicatesthe
outcomeofanattempttounderstandandsatisfyarequest.The
ReasonPhraseisintendedtogiveashorttextualdescriptionofthe
StatusCode.TheStatusCodeisintendedforusebyautomata,
whereastheReasonPhraseisintendedforthehumanuser.Aclient
isnotrequiredtoexamineordisplaytheReasonPhrase.
Whilethisspecificationsuggestsspecificwordingforthereason
phrase,implementationsMAYchooseothertext,forexample,inthe
languageindicatedintheAcceptLanguageheaderfieldofthe
request.
ThefirstdigitoftheStatusCodedefinestheclassofresponse.
Thelasttwodigitsdonothaveanycategorizationrole.Forthis
reason,anyresponsewithastatuscodebetween100and199is
referredtoasa"1xxresponse",anyresponsewithastatuscode
between200and299asa"2xxresponse",andsoon.SIP/2.0allows
sixvaluesforthefirstdigit:
1xx:Provisionalrequestreceived,continuingtoprocessthe
request
2xx:Successtheactionwassuccessfullyreceived,understood,
andaccepted
3xx:Redirectionfurtheractionneedstobetakeninorderto
completetherequest
4xx:ClientErrortherequestcontainsbadsyntaxorcannotbe
fulfilledatthisserver
5xx:ServerErrortheserverfailedtofulfillanapparently
validrequest
6xx:GlobalFailuretherequestcannotbefulfilledatany
server.
Section21definestheseclassesanddescribestheindividualcodes.
7.3HeaderFields
SIPheaderfieldsaresimilartoHTTPheaderfieldsinbothsyntax
andsemantics.Inparticular,SIPheaderfieldsfollowthe[H4.2]
definitionsofsyntaxforthemessageheaderandtherulesfor
extendingheaderfieldsovermultiplelines.However,thelatteris
specifiedinHTTPwithimplicitwhitespaceandfolding.This
specificationconformstoRFC2234[10]andusesonlyexplicit
whitespaceandfoldingasanintegralpartofthegrammar.
[H4.2]alsospecifiesthatmultipleheaderfieldsofthesamefield
namewhosevalueisacommaseparatedlistcanbecombinedintoone
headerfield.ThatappliestoSIPaswell,butthespecificruleis
differentbecauseofthedifferentgrammars.Specifically,anySIP
headerwhosegrammarisoftheform
header="headername"HCOLONheadervalue*(COMMAheadervalue)
allowsforcombiningheaderfieldsofthesamenameintoacomma
separatedlist.TheContactheaderfieldallowsacommaseparated
listunlesstheheaderfieldvalueis"*".
7.3.1HeaderFieldFormat
Headerfieldsfollowthesamegenericheaderformatasthatgivenin
Section2.2ofRFC2822[3].Eachheaderfieldconsistsofafield
namefollowedbyacolon(":")andthefieldvalue.
fieldname:fieldvalue
TheformalgrammarforamessageheaderspecifiedinSection25
allowsforanarbitraryamountofwhitespaceoneithersideofthe
colonhowever,implementationsshouldavoidspacesbetweenthefield
nameandthecolonanduseasinglespace(SP)betweenthecolonand
thefieldvalue.
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,RecordRoute,ProxyRequire,
MaxForwards,andProxyAuthorization,forexample)appeartowards
thetopofthemessagetofacilitaterapidparsing.Therelative
orderofheaderfieldrowswiththesamefieldnameisimportant.
MultipleheaderfieldrowswiththesamefieldnameMAYbepresentin
amessageifandonlyiftheentirefieldvalueforthatheaderfield
isdefinedasacommaseparatedlist(thatis,iffollowsthegrammar
definedinSection7.3).ItMUSTbepossibletocombinethemultiple
headerfieldrowsintoone"fieldname:fieldvalue"pair,without
changingthesemanticsofthemessage,byappendingeachsubsequent
fieldvaluetothefirst,eachseparatedbyacomma.Theexceptions
tothisrulearetheWWWAuthenticate,Authorization,Proxy
Authenticate,andProxyAuthorizationheaderfields.Multipleheader
fieldrowswiththesenamesMAYbepresentinamessage,butsince
theirgrammardoesnotfollowthegeneralformlistedinSection7.3,
theyMUSTNOTbecombinedintoasingleheaderfieldrow.
ImplementationsMUSTbeabletoprocessmultipleheaderfieldrows
withthesamenameinanycombinationofthesinglevalueperlineor
commaseparatedvalueforms.
Thefollowinggroupsofheaderfieldrowsarevalidandequivalent:
Route:<sip:alice@atlanta.com>
Subject:Lunch
Route:<sip:bob@biloxi.com>
Route:<sip:carol@chicago.com>
Route:<sip:alice@atlanta.com>,<sip:bob@biloxi.com>
Subject:Lunch
Subject:Lunch
Route:<sip:alice@atlanta.com>,<sip:bob@biloxi.com>,
<sip:carol@chicago.com>
Eachofthefollowingblocksisvalidbutnotequivalenttothe
others:
Route:<sip:alice@atlanta.com>,<sip:carol@chicago.com>,
<sip:bob@biloxi.com>
Theformatofaheaderfieldvalueisdefinedperheadername.It
willalwaysbeeitheranopaquesequenceofTEXTUTF8octets,ora
combinationofwhitespace,tokens,separators,andquotedstrings.
Manyexistingheaderfieldswilladheretothegeneralformofa
valuefollowedbyasemicolonseparatedsequenceofparametername,
parametervaluepairs:
fieldname:fieldvalue*(parametername=parametervalue)
Eventhoughanarbitrarynumberofparameterpairsmaybeattachedto
aheaderfieldvalue,anygivenparameternameMUSTNOTappearmore
thanonce.
Whencomparingheaderfields,fieldnamesarealwayscase
insensitive.Unlessotherwisestatedinthedefinitionofa
particularheaderfield,fieldvalues,parameternames,andparameter
valuesarecaseinsensitive.Tokensarealwayscaseinsensitive.
Unlessspecifiedotherwise,valuesexpressedasquotedstringsare
casesensitive.Forexample,
Contact:<sip:alice@atlanta.com>expires=3600
isequivalentto
CONTACT:<sip:alice@atlanta.com>ExPiReS=3600
and
ContentDisposition:sessionhandling=optional
isequivalentto
contentdisposition:SessionHANDLING=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
fieldnameMAYappearinbothlongandshortformswithinthesame
message.ImplementationsMUSTacceptboththelongandshortforms
ofeachheadername.
7.4Bodies
Requests,includingnewrequestsdefinedinextensionstothis
specification,MAYcontainmessagebodiesunlessotherwisenoted.
Theinterpretationofthebodydependsontherequestmethod.
Forresponsemessages,therequestmethodandtheresponsestatus
codedeterminethetypeandinterpretationofanymessagebody.All
responsesMAYincludeabody.
7.4.1MessageBodyType
TheInternetmediatypeofthemessagebodyMUSTbegivenbythe
ContentTypeheaderfield.Ifthebodyhasundergoneanyencoding
suchascompression,thenthisMUSTbeindicatedbytheContent
Encodingheaderfieldotherwise,ContentEncodingMUSTbeomitted.
Ifapplicable,thecharactersetofthemessagebodyisindicatedas
partoftheContentTypeheaderfieldvalue.
The"multipart"MIMEtypedefinedinRFC2046[11]MAYbeusedwithin
thebodyofthemessage.Implementationsthatsendrequests
containingmultipartmessagebodiesMUSTsendasessiondescription
asanonmultipartmessagebodyiftheremoteimplementationrequests
thisthroughanAcceptheaderfieldthatdoesnotcontainmultipart.
SIPmessagesMAYcontainbinarybodiesorbodyparts.Whenno
explicitcharsetparameterisprovidedbythesender,mediasubtypes
ofthe"text"typearedefinedtohaveadefaultcharsetvalueof
"UTF8".
7.4.2MessageBodyLength
ThebodylengthinbytesisprovidedbytheContentLengthheader
field.Section20.14describesthenecessarycontentsofthisheader
fieldindetail.
The"chunked"transferencodingofHTTP/1.1MUSTNOTbeusedforSIP.
(Note:Thechunkedencodingmodifiesthebodyofamessageinorder
totransferitasaseriesofchunks,eachwithitsownsize
indicator.)
7.5FramingSIPMessages
UnlikeHTTP,SIPimplementationscanuseUDPorotherunreliable
datagramprotocols.Eachsuchdatagramcarriesonerequestor
response.SeeSection18onconstraintsonusageofunreliable
transports.
ImplementationsprocessingSIPmessagesoverstreamoriented
transportsMUSTignoreanyCRLFappearingbeforethestartline
[H4.1].
TheContentLengthheaderfieldvalueisusedtolocatetheendof
eachSIPmessageinastream.ItwillalwaysbepresentwhenSIP
messagesaresentoverstreamorientedtransports.
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
thoroughlyinSection12theyrepresentapeertopeerrelationship
betweenuseragentsandareestablishedbyspecificSIPmethods,such
asINVITE.
Inthissection,wediscussthemethodindependentrulesforUACand
UASbehaviorwhenprocessingrequeststhatareoutsideofadialog.
Thisincludes,ofcourse,therequestswhichthemselvesestablisha
dialog.
Securityproceduresforrequestsandresponsesoutsideofadialog
aredescribedinSection26.Specifically,mechanismsexistforthe
UASandUACtomutuallyauthenticate.Alimitedsetofprivacy
featuresarealsosupportedthroughencryptionofbodiesusing
S/MIME.
8.1UACBehavior
ThissectioncoversUACbehavioroutsideofadialog.
8.1.1GeneratingtheRequest
AvalidSIPrequestformulatedbyaUACMUST,ataminimum,contain
thefollowingheaderfields:To,From,CSeq,CallID,MaxForwards,
andViaalloftheseheaderfieldsaremandatoryinallSIP
requests.Thesesixheaderfieldsarethefundamentalbuilding
blocksofaSIPmessage,astheyjointlyprovideformostofthe
criticalmessageroutingservicesincludingtheaddressingof
messages,theroutingofresponses,limitingmessagepropagation,
orderingofmessages,andtheuniqueidentificationoftransactions.
Theseheaderfieldsareinadditiontothemandatoryrequestline,
whichcontainsthemethod,RequestURI,andSIPversion.
ExamplesofrequestssentoutsideofadialogincludeanINVITEto
establishasession(Section13)andanOPTIONStoqueryfor
capabilities(Section11).
8.1.1.1RequestURI
TheinitialRequestURIofthemessageSHOULDbesettothevalueof
theURIintheTofield.OnenotableexceptionistheREGISTER
methodbehaviorforsettingtheRequestURIofREGISTERisgivenin
Section10.Itmayalsobeundesirableforprivacyreasonsor
conveniencetosetthesefieldstothesamevalue(especiallyifthe
originatingUAexpectsthattheRequestURIwillbechangedduring
transit).
Insomespecialcircumstances,thepresenceofapreexistingroute
setcanaffecttheRequestURIofthemessage.Apreexistingroute
setisanorderedsetofURIsthatidentifyachainofservers,to
whichaUACwillsendoutgoingrequeststhatareoutsideofadialog.
Commonly,theyareconfiguredontheUAbyauserorserviceprovider
manually,orthroughsomeothernonSIPmechanism.Whenaprovider
wishestoconfigureaUAwithanoutboundproxy,itisRECOMMENDED
thatthisbedonebyprovidingitwithapreexistingroutesetwith
asingleURI,thatoftheoutboundproxy.
Whenapreexistingroutesetispresent,theproceduresfor
populatingtheRequestURIandRouteheaderfielddetailedinSection
12.2.1.1MUSTbefollowed(eventhoughthereisnodialog),usingthe
desiredRequestURIastheremotetargetURI.
8.1.1.2To
TheToheaderfieldfirstandforemostspecifiesthedesired
"logical"recipientoftherequest,ortheaddressofrecordofthe
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
resolvedinthedomaintotherighthandside(RHS)oftheatsignin
theSIPURI(forinstance,sip:bob@example.com).Usingthestringto
formtheuserpartofaSIPSURIimpliesthattheUAwishesto
communicatesecurely,andthatthenameistoberesolvedinthe
domaintotheRHSoftheatsign.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.
ArequestoutsideofadialogMUSTNOTcontainaTotagthetagin
theTofieldofarequestidentifiesthepeerofthedialog.Since
nodialogisestablished,notagispresent.
ForfurtherinformationontheToheaderfield,seeSection20.39.
ThefollowingisanexampleofavalidToheaderfield:
To:Carol<sip:carol@chicago.com>
8.1.1.3From
TheFromheaderfieldindicatesthelogicalidentityoftheinitiator
oftherequest,possiblytheuser'saddressofrecord.LiketheTo
headerfield,itcontainsaURIandoptionallyadisplayname.Itis
usedbySIPelementstodeterminewhichprocessingrulestoapplyto
arequest(forexample,automaticcallrejection).Assuch,itis
veryimportantthattheFromURInotcontainIPaddressesortheFQDN
ofthehostonwhichtheUAisrunning,sincethesearenotlogical
names.
TheFromheaderfieldallowsforadisplayname.AUACSHOULDuse
thedisplayname"Anonymous",alongwithasyntacticallycorrect,but
otherwisemeaninglessURI(likesip:thisis@anonymous.invalid),ifthe
identityoftheclientistoremainhidden.
Usually,thevaluethatpopulatestheFromheaderfieldinrequests
generatedbyaparticularUAispreprovisionedbytheuserorbythe
administratorsoftheuser'slocaldomain.IfaparticularUAis
usedbymultipleusers,itmighthaveswitchableprofilesthat
includeaURIcorrespondingtotheidentityoftheprofileduser.
Recipientsofrequestscanauthenticatetheoriginatorofarequest
inordertoascertainthattheyarewhotheirFromheaderfield
claimstheyare(seeSection22formoreonauthentication).
TheFromfieldMUSTcontainanew"tag"parameter,chosenbytheUAC.
SeeSection19.3fordetailsonchoosingatag.
ForfurtherinformationontheFromheaderfield,seeSection20.20.
Examples:
From:"Bob"<sips:bob@biloxi.com>tag=a48s
From:sip:+12125551212@phone2net.comtag=887s
From:Anonymous<sip:c8oqz84zk7z@privacy.org>tag=hyh8
8.1.1.4CallID
TheCallIDheaderfieldactsasauniqueidentifiertogroup
togetheraseriesofmessages.ItMUSTbethesameforallrequests
andresponsessentbyeitherUAinadialog.ItSHOULDbethesame
ineachregistrationfromaUA.
InanewrequestcreatedbyaUACoutsideofanydialog,theCallID
headerfieldMUSTbeselectedbytheUACasagloballyunique
identifieroverspaceandtimeunlessoverriddenbymethodspecific
behavior.AllSIPUAsmusthaveameanstoguaranteethattheCall
IDheaderfieldstheyproducewillnotbeinadvertentlygeneratedby
anyotherUA.Notethatwhenrequestsareretriedaftercertain
failureresponsesthatsolicitanamendmenttoarequest(for
example,achallengeforauthentication),theseretriedrequestsare
notconsiderednewrequests,andthereforedonotneednewCallID
headerfieldsseeSection8.1.3.5.
Useofcryptographicallyrandomidentifiers(RFC1750[12])inthe
generationofCallIDsisRECOMMENDED.ImplementationsMAYusethe
form"localid@host".CallIDsarecasesensitiveandaresimply
comparedbytebybyte.
Usingcryptographicallyrandomidentifiersprovidessome
protectionagainstsessionhijackingandreducesthelikelihoodof
unintentionalCallIDcollisions.
Noprovisioningorhumaninterfaceisrequiredfortheselectionof
theCallIDheaderfieldvalueforarequest.
ForfurtherinformationontheCallIDheaderfield,seeSection
20.8.
Example:
CallID:f81d4fae7dec11d0a76500a0c91e6bf6@foo.bar.com
8.1.1.5CSeq
TheCSeqheaderfieldservesasawaytoidentifyandorder
transactions.Itconsistsofasequencenumberandamethod.The
methodMUSTmatchthatoftherequest.FornonREGISTERrequests
outsideofadialog,thesequencenumbervalueisarbitrary.The
sequencenumbervalueMUSTbeexpressibleasa32bitunsigned
integerandMUSTbelessthan2**31.Aslongasitfollowstheabove
guidelines,aclientmayuseanymechanismitwouldliketoselect
CSeqheaderfieldvalues.
Section12.2.1.1discussesconstructionoftheCSeqforrequests
withinadialog.
Example:
CSeq:4711INVITE
8.1.1.6MaxForwards
TheMaxForwardsheaderfieldservestolimitthenumberofhopsa
requestcantransitonthewaytoitsdestination.Itconsistsofan
integerthatisdecrementedbyoneateachhop.IftheMaxForwards
valuereaches0beforetherequestreachesitsdestination,itwill
berejectedwitha483(TooManyHops)errorresponse.
AUACMUSTinsertaMaxForwardsheaderfieldintoeachrequestit
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
andACKfornon2xxresponses.Asdiscussedbelow,aCANCELrequest
willhavethesamevalueofthebranchparameterastherequestit
cancels.AsdiscussedinSection17.1.1.3,anACKforanon2xx
responsewillalsohavethesamebranchIDastheINVITEwhose
responseitacknowledges.
TheuniquenesspropertyofthebranchIDparameter,tofacilitate
itsuseasatransactionID,wasnotpartofRFC2543.
ThebranchIDinsertedbyanelementcompliantwiththis
specificationMUSTalwaysbeginwiththecharacters"z9hG4bK".These
7charactersareusedasamagiccookie(7isdeemedsufficientto
ensurethatanolderRFC2543implementationwouldnotpicksucha
value),sothatserversreceivingtherequestcandeterminethatthe
branchIDwasconstructedinthefashiondescribedbythis
specification(thatis,globallyunique).Beyondthisrequirement,
thepreciseformatofthebranchtokenisimplementationdefined.
TheViaheadermaddr,ttl,andsentbycomponentswillbesetwhen
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.
IftheRequestURIortopRouteheaderfieldvaluecontainsaSIPS
URI,theContactheaderfieldMUSTcontainaSIPSURIaswell.
ForfurtherinformationontheContactheaderfield,seeSection
20.10.
8.1.1.9SupportedandRequire
IftheUACsupportsextensionstoSIPthatcanbeappliedbythe
servertotheresponse,theUACSHOULDincludeaSupportedheader
fieldintherequestlistingtheoptiontags(Section19.2)forthose
extensions.
TheoptiontagslistedMUSTonlyrefertoextensionsdefinedin
standardstrackRFCs.Thisistopreventserversfrominsistingthat
clientsimplementnonstandard,vendordefinedfeaturesinorderto
receiveservice.Extensionsdefinedbyexperimentaland
informationalRFCsareexplicitlyexcludedfromusagewiththe
Supportedheaderfieldinarequest,sincetheytooareoftenusedto
documentvendordefinedextensions.
IftheUACwishestoinsistthataUASunderstandanextensionthat
theUACwillapplytotherequestinordertoprocesstherequest,it
MUSTinsertaRequireheaderfieldintotherequestlistingthe
optiontagforthatextension.IftheUACwishestoapplyan
extensiontotherequestandinsistthatanyproxiesthatare
traversedunderstandthatextension,itMUSTinsertaProxyRequire
headerfieldintotherequestlistingtheoptiontagforthat
extension.
AswiththeSupportedheaderfield,theoptiontagsintheRequire
andProxyRequireheaderfieldsMUSTonlyrefertoextensionsdefined
instandardstrackRFCs.
8.1.1.10AdditionalMessageComponents
Afteranewrequesthasbeencreated,andtheheaderfieldsdescribed
abovehavebeenproperlyconstructed,anyadditionaloptionalheader
fieldsareadded,asareanyheaderfieldsspecifictothemethod.
SIPrequestsMAYcontainaMIMEencodedmessagebody.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
proceduresMUSTbeappliedtotheRequestURIoftherequest.
Otherwise,theproceduresareappliedtothefirstRouteheaderfield
valueintherequest(ifoneexists),ortotherequest'sRequestURI
ifthereisnoRouteheaderfieldpresent.Theseproceduresyieldan
orderedsetofaddress,port,andtransportstoattempt.Independent
ofwhichURIisusedasinputtotheproceduresof[4],ifthe
RequestURIspecifiesaSIPSresource,theUACMUSTfollowthe
proceduresof[4]asiftheinputURIwereaSIPSURI.
LocalpolicyMAYspecifyanalternatesetofdestinationstoattempt.
IftheRequestURIcontainsaSIPSURI,anyalternatedestinations
MUSTbecontactedwithTLS.Beyondthat,therearenorestrictions
onthealternatedestinationsiftherequestcontainsnoRouteheader
field.Thisprovidesasimplealternativetoapreexistingroute
setasawaytospecifyanoutboundproxy.However,thatapproach
forconfiguringanoutboundproxyisNOTRECOMMENDEDapreexisting
routesetwithasingleURISHOULDbeusedinstead.Iftherequest
containsaRouteheaderfield,therequestSHOULDbesenttothe
locationsderivedfromitstopmostvalue,butMAYbesenttoany
serverthattheUAiscertainwillhonortheRouteandRequestURI
policiesspecifiedinthisdocument(asopposedtothoseinRFC
2543).Inparticular,aUACconfiguredwithanoutboundproxySHOULD
attempttosendtherequesttothelocationindicatedinthefirst
Routeheaderfieldvalueinsteadofadoptingthepolicyofsending
allmessagestotheoutboundproxy.
ThisensuresthatoutboundproxiesthatdonotaddRecordRoute
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.
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
RequestURIoftheoriginalrequest.Ifaclientwishestoformulate
newrequestsbasedona3xxclassresponsetothatrequest,itplaces
theURIstotryintothetargetset.Subjecttotherestrictionsin
thisspecification,aclientcanchoosewhichContactURIsitplaces
intothetargetset.Aswithproxyrecursion,aclientprocessing
3xxclassresponsesMUSTNOTaddanygivenURItothetargetsetmore
thanonce.IftheoriginalrequesthadaSIPSURIintheRequest
URI,theclientMAYchoosetorecursetoanonSIPSURI,butSHOULD
informtheuseroftheredirectiontoaninsecureURI.
Anynewrequestmayreceive3xxresponsesthemselvescontaining
theoriginalURIasacontact.Twolocationscanbeconfiguredto
redirecttoeachother.PlacinganygivenURIinthetargetset
onlyoncepreventsinfiniteredirectionloops.
Asthetargetsetgrows,theclientMAYgeneratenewrequeststothe
URIsinanyorder.Acommonmechanismistoorderthesetbythe"q"
parametervaluefromtheContactheaderfieldvalue.Requeststothe
URIsMAYbegeneratedseriallyorinparallel.Oneapproachisto
processgroupsofdecreasingqvaluesseriallyandprocesstheURIs
ineachqvaluegroupinparallel.Anotheristoperformonlyserial
processingindecreasingqvalueorder,arbitrarilychoosingbetween
contactsofequalqvalue.
Ifcontactinganaddressinthelistresultsinafailure,asdefined
inthenextparagraph,theelementmovestothenextaddressinthe
list,untilthelistisexhausted.Ifthelistisexhausted,then
therequesthasfailed.
FailuresSHOULDbedetectedthroughfailureresponsecodes(codes
greaterthan399)fornetworkerrorstheclienttransactionwill
reportanytransportlayerfailurestothetransactionuser.Note
thatsomeresponsecodes(detailedin8.1.3.5)indicatethatthe
requestcanberetriedrequeststhatarereattemptedshouldnotbe
consideredfailures.
Whenafailureforaparticularcontactaddressisreceived,the
clientSHOULDtrythenextcontactaddress.Thiswillinvolve
creatinganewclienttransactiontodeliveranewrequest.
Inordertocreatearequestbasedonacontactaddressina3xx
response,aUACMUSTcopytheentireURIfromthetargetsetintothe
RequestURI,exceptforthe"methodparam"and"header"URI
parameters(seeSection19.1.1foradefinitionoftheseparameters).
Itusesthe"header"parameterstocreateheaderfieldvaluesforthe
newrequest,overwritingheaderfieldvaluesassociatedwiththe
redirectedrequestinaccordancewiththeguidelinesinSection
19.1.5.
Notethatinsomeinstances,headerfieldsthathavebeen
communicatedinthecontactaddressmayinsteadappendtoexisting
requestheaderfieldsintheoriginalredirectedrequest.Asa
generalrule,iftheheaderfieldcanacceptacommaseparatedlist
ofvalues,thenthenewheaderfieldvalueMAYbeappendedtoany
existingvaluesintheoriginalredirectedrequest.Iftheheader
fielddoesnotacceptmultiplevalues,thevalueintheoriginal
redirectedrequestMAYbeoverwrittenbytheheaderfieldvalue
communicatedinthecontactaddress.Forexample,ifacontact
addressisreturnedwiththefollowingvalue:
sip:user@host?Subject=foo&CallInfo=<http://www.foo.com>
ThenanySubjectheaderfieldintheoriginalredirectedrequestis
overwritten,buttheHTTPURLismerelyappendedtoanyexisting
CallInfoheaderfieldvalues.
ItisRECOMMENDEDthattheUACreusethesameTo,From,andCallID
usedintheoriginalredirectedrequest,buttheUACMAYalsochoose
toupdatetheCallIDheaderfieldvaluefornewrequests,for
example.
Finally,oncethenewrequesthasbeenconstructed,itissentusing
anewclienttransaction,andthereforeMUSThaveanewbranchIDin
thetopViafieldasdiscussedinSection8.1.1.7.
Inallotherrespects,requestssentuponreceiptofaredirect
responseSHOULDreusetheheaderfieldsandbodiesoftheoriginal
request.
Insomeinstances,ContactheaderfieldvaluesmaybecachedatUAC
temporarilyorpermanentlydependingonthestatuscodereceivedand
thepresenceofanexpirationintervalseeSections21.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,
withencodingslistedintheAcceptEncodingheaderfieldinthe
response,andwithlanguageslistedintheAcceptLanguageinthe
response.
Ifa416(UnsupportedURIScheme)responseisreceived(Section
21.4.14),theRequestURIusedaURIschemenotsupportedbythe
server.TheclientSHOULDretrytherequest,thistime,usingaSIP
URI.
Ifa420(BadExtension)responseisreceived(Section21.4.15),the
requestcontainedaRequireorProxyRequireheaderfieldlistingan
optiontagforafeaturenotsupportedbyaproxyorUAS.TheUAC
SHOULDretrytherequest,thistimeomittinganyextensionslistedin
theUnsupportedheaderfieldintheresponse.
Inalloftheabovecases,therequestisretriedbycreatinganew
requestwiththeappropriatemodifications.Thisnewrequest
constitutesanewtransactionandSHOULDhavethesamevalueofthe
CallID,To,andFromofthepreviousrequest,buttheCSeqshould
containanewsequencenumberthatisonehigherthantheprevious.
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.1ToandRequestURI
TheToheaderfieldidentifiestheoriginalrecipientoftherequest
designatedbytheuseridentifiedintheFromfield.Theoriginal
recipientmayormaynotbetheUASprocessingtherequest,dueto
callforwardingorotherproxyoperations.AUASMAYapplyany
policyitwishestodeterminewhethertoacceptrequestswhentheTo
headerfieldisnottheidentityoftheUAS.However,itis
RECOMMENDEDthataUASacceptrequestseveniftheydonotrecognize
theURIscheme(forexample,atel:URI)intheToheaderfield,or
iftheToheaderfielddoesnotaddressaknownorcurrentuserof
thisUAS.If,ontheotherhand,theUASdecidestorejectthe
request,itSHOULDgeneratearesponsewitha403(Forbidden)status
codeandpassittotheservertransactionfortransmission.
However,theRequestURIidentifiestheUASthatistoprocessthe
request.IftheRequestURIusesaschemenotsupportedbytheUAS,
itSHOULDrejecttherequestwitha416(UnsupportedURIScheme)
response.IftheRequestURIdoesnotidentifyanaddressthatthe
UASiswillingtoacceptrequestsfor,itSHOULDrejecttherequest
witha404(NotFound)response.Typically,aUAthatusesthe
REGISTERmethodtobinditsaddressofrecordtoaspecificcontact
addresswillseerequestswhoseRequestURIequalsthatcontact
address.OtherpotentialsourcesofreceivedRequestURIsinclude
theContactheaderfieldsofrequestsandresponsessentbytheUA
thatestablishorrefreshdialogs.
8.2.2.2MergedRequests
IftherequesthasnotagintheToheaderfield,theUAScoreMUST
checktherequestagainstongoingtransactions.IftheFromtag,
CallID,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.IfaUASdoesnotunderstandanoptiontaglistedina
Requireheaderfield,itMUSTrespondbygeneratingaresponsewith
statuscode420(BadExtension).TheUASMUSTaddanUnsupported
headerfield,andlistinitthoseoptionsitdoesnotunderstand
amongstthoseintheRequireheaderfieldoftherequest.
NotethatRequireandProxyRequireMUSTNOTbeusedinaSIPCANCEL
request,orinanACKrequestsentforanon2xxresponse.These
headerfieldsMUSTbeignorediftheyarepresentintheserequests.
AnACKrequestfora2xxresponseMUSTcontainonlythoseRequireand
ProxyRequirevaluesthatwerepresentintheinitialrequest.
Example:
UAC>UAS:INVITEsip:watson@belltelephone.comSIP/2.0
Require:100rel
UAS>UAC:SIP/2.0420BadExtension
Unsupported:100rel
Thisbehaviorensuresthattheclientserverinteractionwill
proceedwithoutdelaywhenalloptionsareunderstoodbyboth
sides,andonlyslowdownifoptionsarenotunderstood(asinthe
exampleabove).Forawellmatchedclientserverpair,the
interactionproceedsquickly,savingaroundtripoftenrequired
bynegotiationmechanisms.Inaddition,italsoremovesambiguity
whentheclientrequiresfeaturesthattheserverdoesnot
understand.Somefeatures,suchascallhandlingfields,areonly
ofinteresttoendsystems.
8.2.3ContentProcessing
AssumingtheUASunderstandsanyextensionsrequiredbytheclient,
theUASexaminesthebodyofthemessage,andtheheaderfieldsthat
describeit.Ifthereareanybodieswhosetype(indicatedbythe
ContentType),language(indicatedbytheContentLanguage)or
encoding(indicatedbytheContentEncoding)arenotunderstood,and
thatbodypartisnotoptional(asindicatedbytheContent
Dispositionheaderfield),theUASMUSTrejecttherequestwitha415
(UnsupportedMediaType)response.TheresponseMUSTcontainan
Acceptheaderfieldlistingthetypesofallbodiesitunderstands,
intheeventtherequestcontainedbodiesoftypesnotsupportedby
theUAS.Iftherequestcontainedcontentencodingsnotunderstood
bytheUAS,theresponseMUSTcontainanAcceptEncodingheaderfield
listingtheencodingsunderstoodbytheUAS.Iftherequest
containedcontentwithlanguagesnotunderstoodbytheUAS,the
responseMUSTcontainanAcceptLanguageheaderfieldindicatingthe
languagesunderstoodbytheUAS.Beyondthesechecks,bodyhandling
dependsonthemethodandtype.Forfurtherinformationonthe
processingofcontentspecificheaderfields,seeSection7.4aswell
asSection20.11through20.15.
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.
Anyextensionsappliedtoanon421responseMUSTbelistedina
Requireheaderfieldincludedintheresponse.Ofcourse,theserver
MUSTNOTapplyextensionsnotlistedintheSupportedheaderfieldin
therequest.Asaresultofthis,theRequireheaderfieldina
responsewillonlyevercontainoptiontagsdefinedinstandards
trackRFCs.
8.2.5ProcessingtheRequest
Assumingallofthechecksintheprevioussubsectionsarepassed,
theUASprocessingbecomesmethodspecific.Section10coversthe
REGISTERrequest,Section11coverstheOPTIONSrequest,Section13
coverstheINVITErequest,andSection15coverstheBYErequest.
8.2.6GeneratingtheResponse
WhenaUASwishestoconstructaresponsetoarequest,itfollows
thegeneralproceduresdetailedinthefollowingsubsections.
Additionalbehaviorsspecifictotheresponsecodeinquestion,which
arenotdetailedinthissection,mayalsoberequired.
Onceallproceduresassociatedwiththecreationofaresponsehave
beencompleted,theUAShandstheresponsebacktotheserver
transactionfromwhichitreceivedtherequest.
8.2.6.1SendingaProvisionalResponse
Onelargelynonmethodspecificguidelineforthegenerationof
responsesisthatUASsSHOULDNOTissueaprovisionalresponsefora
nonINVITErequest.Rather,UASsSHOULDgenerateafinalresponseto
anonINVITErequestassoonaspossible.
Whena100(Trying)responseisgenerated,anyTimestampheaderfield
presentintherequestMUSTbecopiedintothis100(Trying)
response.Ifthereisadelayingeneratingtheresponse,theUAS
SHOULDaddadelayvalueintotheTimestampvalueintheresponse.
ThisvalueMUSTcontainthedifferencebetweenthetimeofsendingof
theresponseandreceiptoftherequest,measuredinseconds.
8.2.6.2HeadersandTags
TheFromfieldoftheresponseMUSTequaltheFromheaderfieldof
therequest.TheCallIDheaderfieldoftheresponseMUSTequalthe
CallIDheaderfieldoftherequest.TheCSeqheaderfieldofthe
responseMUSTequaltheCSeqfieldoftherequest.TheViaheader
fieldvaluesintheresponseMUSTequaltheViaheaderfieldvalues
intherequestandMUSTmaintainthesameordering.
IfarequestcontainedaTotagintherequest,theToheaderfield
intheresponseMUSTequalthatoftherequest.However,iftheTo
headerfieldintherequestdidnotcontainatag,theURIintheTo
headerfieldintheresponseMUSTequaltheURIintheToheader
fieldadditionally,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.StatelessUASsdonotuseatransactionlayerthey
receiverequestsdirectlyfromthetransportlayerandsendresponses
directlytothetransportlayer.
ThestatelessUASroleisneededprimarilytohandleunauthenticated
requestsforwhichachallengeresponseisissued.If
unauthenticatedrequestswerehandledstatefully,thenmalicious
floodsofunauthenticatedrequestscouldcreatemassiveamountsof
transactionstatethatmightsloworcompletelyhaltcallprocessing
inaUAS,effectivelycreatingadenialofserviceconditionfor
moreinformationseeSection26.1.5.
ThemostimportantbehaviorsofastatelessUASarethefollowing:
oAstatelessUASMUSTNOTsendprovisional(1xx)responses.
oAstatelessUASMUSTNOTretransmitresponses.
oAstatelessUASMUSTignoreACKrequests.
oAstatelessUASMUSTignoreCANCELrequests.
oToheadertagsMUSTbegeneratedforresponsesinastateless
mannerinamannerthatwillgeneratethesametagforthe
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
locationserviceandreturnsafinalresponseofclass3xx.For
wellformedCANCELrequests,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
totheoneintheRequestURIinstead,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
nonSIPSURI.
The"expires"parameterofaContactheaderfieldvalueindicateshow
longtheURIisvalid.Thevalueoftheparameterisanumber
indicatingseconds.Ifthisparameterisnotprovided,thevalueof
theExpiresheaderfielddetermineshowlongtheURIisvalid.
MalformedvaluesSHOULDbetreatedasequivalentto3600.
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"hopbyhop"request,sinceitis
respondedtoateachstatefulproxyhop.
9.1ClientBehavior
ACANCELrequestSHOULDNOTbesenttocancelarequestotherthan
INVITE.
SincerequestsotherthanINVITEarerespondedtoimmediately,
sendingaCANCELforanonINVITErequestwouldalwayscreatea
racecondition.
ThefollowingproceduresareusedtoconstructaCANCELrequest.The
RequestURI,CallID,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.
TheCANCELrequestMUSTNOTcontainanyRequireorProxyRequire
headerfields.
OncetheCANCELisconstructed,theclientSHOULDcheckwhetherit
hasreceivedanyresponse(provisionalorfinal)fortherequest
beingcancelled(hereinreferredtoasthe"originalrequest").
Ifnoprovisionalresponsehasbeenreceived,theCANCELrequestMUST
NOTbesentrather,theclientMUSTwaitforthearrivalofa
provisionalresponsebeforesendingtherequest.Iftheoriginal
requesthasgeneratedafinalresponse,theCANCELSHOULDNOTbe
sent,asitisaneffectivenoop,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
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
arehopbyhopandcannotberesubmitted,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.
10Registrations
10.1Overview
SIPoffersadiscoverycapability.Ifauserwantstoinitiatea
sessionwithanotheruser,SIPmustdiscoverthecurrenthost(s)at
whichthedestinationuserisreachable.Thisdiscoveryprocessis
frequentlyaccomplishedbySIPnetworkelementssuchasproxyservers
andredirectserverswhichareresponsibleforreceivingarequest,
determiningwheretosenditbasedonknowledgeofthelocationof
theuser,andthensendingitthere.Todothis,SIPnetwork
elementsconsultanabstractserviceknownasalocationservice,
whichprovidesaddressbindingsforaparticulardomain.These
addressbindingsmapanincomingSIPorSIPSURI,sip:bob@biloxi.com,
forexample,tooneormoreURIsthataresomehow"closer"tothe
desireduser,sip:bob@engineering.biloxi.com,forexample.
Ultimately,aproxywillconsultalocationservicethatmapsa
receivedURItotheuseragent(s)atwhichthedesiredrecipientis
currentlyresiding.
Registrationcreatesbindingsinalocationserviceforaparticular
domainthatassociatesanaddressofrecordURIwithoneormore
contactaddresses.Thus,whenaproxyforthatdomainreceivesa
requestwhoseRequestURImatchestheaddressofrecord,theproxy
willforwardtherequesttothecontactaddressesregisteredtothat
addressofrecord.Generally,itonlymakessensetoregisteran
addressofrecordatadomain'slocationservicewhenrequestsfor
thataddressofrecordwouldberoutedtothatdomain.Inmost
cases,thismeansthatthedomainoftheregistrationwillneedto
matchthedomainintheURIoftheaddressofrecord.
Therearemanywaysbywhichthecontentsofthelocationservicecan
beestablished.Onewayisadministratively.Intheaboveexample,
Bobisknowntobeamemberoftheengineeringdepartmentthrough
accesstoacorporatedatabase.However,SIPprovidesamechanism
foraUAtocreateabindingexplicitly.Thismechanismisknownas
registration.
RegistrationentailssendingaREGISTERrequesttoaspecialtypeof
UASknownasaregistrar.Aregistraractsasthefrontendtothe
locationserviceforadomain,readingandwritingmappingsbasedon
thecontentsofREGISTERrequests.Thislocationserviceisthen
typicallyconsultedbyaproxyserverthatisresponsibleforrouting
requestsforthatdomain.
Anillustrationoftheoverallregistrationprocessisgivenin
Figure2.Notethattheregistrarandproxyserverarelogicalroles
thatcanbeplayedbyasingledeviceinanetworkforpurposesof
claritythetwoareseparatedinthisillustration.Alsonotethat
UAsmaysendrequeststhroughaproxyserverinordertoreacha
registrarifthetwoareseparateelements.
SIPdoesnotmandateaparticularmechanismforimplementingthe
locationservice.Theonlyrequirementisthataregistrarforsome
domainMUSTbeabletoreadandwritedatatothelocationservice,
andaproxyoraredirectserverforthatdomainMUSTbecapableof
readingthatsamedata.AregistrarMAYbecolocatedwitha
particularSIPproxyserverforthesamedomain.
10.2ConstructingtheREGISTERRequest
REGISTERrequestsadd,remove,andquerybindings.AREGISTER
requestcanaddanewbindingbetweenanaddressofrecordandoneor
morecontactaddresses.Registrationonbehalfofaparticular
addressofrecordcanbeperformedbyasuitablyauthorizedthird
party.Aclientcanalsoremovepreviousbindingsorqueryto
determinewhichbindingsarecurrentlyinplaceforanaddressof
record.
Exceptasnoted,theconstructionoftheREGISTERrequestandthe
behaviorofclientssendingaREGISTERrequestisidenticaltothe
generalUACbehaviordescribedinSection8.1andSection17.1.
AREGISTERrequestdoesnotestablishadialog.AUACMAYincludea
RouteheaderfieldinaREGISTERrequestbasedonapreexisting
routesetasdescribedinSection8.1.TheRecordRouteheaderfield
hasnomeaninginREGISTERrequestsorresponses,andMUSTbeignored
ifpresent.Inparticular,theUACMUSTNOTcreateanewrouteset
basedonthepresenceorabsenceofaRecordRouteheaderfieldin
anyresponsetoaREGISTERrequest.
Thefollowingheaderfields,exceptContact,MUSTbeincludedina
REGISTERrequest.AContactheaderfieldMAYbeincluded:
RequestURI:TheRequestURInamesthedomainofthelocation
serviceforwhichtheregistrationismeant(forexample,
"sip:chicago.com").The"userinfo"and"@"componentsofthe
SIPURIMUSTNOTbepresent.
To:TheToheaderfieldcontainstheaddressofrecordwhose
registrationistobecreated,queried,ormodified.TheTo
headerfieldandtheRequestURIfieldtypicallydiffer,as
theformercontainsausername.ThisaddressofrecordMUST
beaSIPURIorSIPSURI.
From:TheFromheaderfieldcontainstheaddressofrecordofthe
personresponsiblefortheregistration.Thevalueisthe
sameastheToheaderfieldunlesstherequestisathird
partyregistration.
CallID:AllregistrationsfromaUACSHOULDusethesameCallID
headerfieldvalueforregistrationssenttoaparticular
registrar.
IfthesameclientweretousedifferentCallIDvalues,a
registrarcouldnotdetectwhetheradelayedREGISTERrequest
mighthavearrivedoutoforder.
CSeq:TheCSeqvalueguaranteesproperorderingofREGISTER
requests.AUAMUSTincrementtheCSeqvaluebyoneforeach
REGISTERrequestwiththesameCallID.
Contact:REGISTERrequestsMAYcontainaContactheaderfieldwith
zeroormorevaluescontainingaddressbindings.
UAsMUSTNOTsendanewregistration(thatis,containingnewContact
headerfieldvalues,asopposedtoaretransmission)untiltheyhave
receivedafinalresponsefromtheregistrarforthepreviousoneor
thepreviousREGISTERrequesthastimedout.
bob
++
|UA|
||
++
|
|3)INVITE
|carol@chicago.com
chicago.com++V
++2)Store|Location|4)Query++
|Registrar|=======>|Service|<=======|Proxy|sip.chicago.com
++++=======>++
A5)Resp|
||
||
1)REGISTER||
||
++|
|UA|<+
cube2214a||6)INVITE
++carol@cube2214a.chicago.com
carol
Figure2:REGISTERexample
ThefollowingContactheaderparametershaveaspecialmeaningin
REGISTERrequests:
action:The"action"parameterfromRFC2543hasbeendeprecated.
UACsSHOULDNOTusethe"action"parameter.
expires:The"expires"parameterindicateshowlongtheUAwould
likethebindingtobevalid.Thevalueisanumber
indicatingseconds.Ifthisparameterisnotprovided,the
valueoftheExpiresheaderfieldisusedinstead.
ImplementationsMAYtreatvalueslargerthan2**321
(4294967295secondsor136years)asequivalentto2**321.
MalformedvaluesSHOULDbetreatedasequivalentto3600.
10.2.1AddingBindings
TheREGISTERrequestsenttoaregistrarincludesthecontact
address(es)towhichSIPrequestsfortheaddressofrecordshouldbe
forwarded.TheaddressofrecordisincludedintheToheaderfield
oftheREGISTERrequest.
TheContactheaderfieldvaluesoftherequesttypicallyconsistof
SIPorSIPSURIsthatidentifyparticularSIPendpoints(forexample,
"sip:carol@cube2214a.chicago.com"),buttheyMAYuseanyURIscheme.
ASIPUAcanchoosetoregistertelephonenumbers(withthetelURL,
RFC2806[9])oremailaddresses(withamailtoURL,RFC2368[32])
asContactsforanaddressofrecord,forexample.
Forexample,Carol,withaddressofrecord"sip:carol@chicago.com",
wouldregisterwiththeSIPregistrarofthedomainchicago.com.Her
registrationswouldthenbeusedbyaproxyserverinthechicago.com
domaintorouterequestsforCarol'saddressofrecordtoherSIP
endpoint.
Onceaclienthasestablishedbindingsataregistrar,itMAYsend
subsequentregistrationscontainingnewbindingsormodificationsto
existingbindingsasnecessary.The2xxresponsetotheREGISTER
requestwillcontain,inaContactheaderfield,acompletelistof
bindingsthathavebeenregisteredforthisaddressofrecordatthis
registrar.
IftheaddressofrecordintheToheaderfieldofaREGISTERrequest
isaSIPSURI,thenanyContactheaderfieldvaluesintherequest
SHOULDalsobeSIPSURIs.ClientsshouldonlyregisternonSIPSURIs
underaSIPSaddressofrecordwhenthesecurityoftheresource
representedbythecontactaddressisguaranteedbyothermeans.
ThismaybeapplicabletoURIsthatinvokeprotocolsotherthanSIP,
orSIPdevicessecuredbyprotocolsotherthanTLS.
Registrationsdonotneedtoupdateallbindings.Typically,aUA
onlyupdatesitsowncontactaddresses.
10.2.1.1SettingtheExpirationIntervalofContactAddresses
WhenaclientsendsaREGISTERrequest,itMAYsuggestanexpiration
intervalthatindicateshowlongtheclientwouldlikethe
registrationtobevalid.(AsdescribedinSection10.3,the
registrarselectstheactualtimeintervalbasedonitslocal
policy.)
Therearetwowaysinwhichaclientcansuggestanexpiration
intervalforabinding:throughanExpiresheaderfieldoran
"expires"Contactheaderparameter.Thelatterallowsexpiration
intervalstobesuggestedonaperbindingbasiswhenmorethanone
bindingisgiveninasingleREGISTERrequest,whereastheformer
suggestsanexpirationintervalforallContactheaderfieldvalues
thatdonotcontainthe"expires"parameter.
Ifneithermechanismforexpressingasuggestedexpirationtimeis
presentinaREGISTER,theclientisindicatingitsdesireforthe
servertochoose.
10.2.1.2PreferencesamongContactAddresses
IfmorethanoneContactissentinaREGISTERrequest,the
registeringUAintendstoassociatealloftheURIsintheseContact
headerfieldvalueswiththeaddressofrecordpresentintheTo
field.Thislistcanbeprioritizedwiththe"q"parameterinthe
Contactheaderfield.The"q"parameterindicatesarelative
preferencefortheparticularContactheaderfieldvaluecomparedto
otherbindingsforthisaddressofrecord.Section16.6describes
howaproxyserverusesthispreferenceindication.
10.2.2RemovingBindings
Registrationsaresoftstateandexpireunlessrefreshed,butcan
alsobeexplicitlyremoved.Aclientcanattempttoinfluencethe
expirationintervalselectedbytheregistrarasdescribedinSection
10.2.1.AUArequeststheimmediateremovalofabindingby
specifyinganexpirationintervalof"0"forthatcontactaddressin
aREGISTERrequest.UAsSHOULDsupportthismechanismsothat
bindingscanberemovedbeforetheirexpirationintervalhaspassed.
TheREGISTERspecificContactheaderfieldvalueof"*"appliesto
allregistrations,butitMUSTNOTbeusedunlesstheExpiresheader
fieldispresentwithavalueof"0".
Useofthe"*"ContactheaderfieldvalueallowsaregisteringUA
toremoveallbindingsassociatedwithanaddressofrecord
withoutknowingtheirprecisevalues.
10.2.3FetchingBindings
AsuccessresponsetoanyREGISTERrequestcontainsthecompletelist
ofexistingbindings,regardlessofwhethertherequestcontaineda
Contactheaderfield.IfnoContactheaderfieldispresentina
REGISTERrequest,thelistofbindingsisleftunchanged.
10.2.4RefreshingBindings
EachUAisresponsibleforrefreshingthebindingsthatithas
previouslyestablished.AUASHOULDNOTrefreshbindingssetupby
otherUAs.
The200(OK)responsefromtheregistrarcontainsalistofContact
fieldsenumeratingallcurrentbindings.TheUAcompareseach
contactaddresstoseeifitcreatedthecontactaddress,using
comparisonrulesinSection19.1.4.Ifso,itupdatestheexpiration
timeintervalaccordingtotheexpiresparameteror,ifabsent,the
Expiresfieldvalue.TheUAthenissuesaREGISTERrequestforeach
ofitsbindingsbeforetheexpirationintervalhaselapsed.ItMAY
combineseveralupdatesintooneREGISTERrequest.
AUASHOULDusethesameCallIDforallregistrationsduringa
singlebootcycle.RegistrationrefreshesSHOULDbesenttothesame
networkaddressastheoriginalregistration,unlessredirected.
10.2.5SettingtheInternalClock
IftheresponseforaREGISTERrequestcontainsaDateheaderfield,
theclientMAYusethisheaderfieldtolearnthecurrenttimein
ordertosetanyinternalclocks.
10.2.6DiscoveringaRegistrar
UAscanusethreewaystodeterminetheaddresstowhichtosend
registrations:byconfiguration,usingtheaddressofrecord,and
multicast.AUAcanbeconfigured,inwaysbeyondthescopeofthis
specification,witharegistraraddress.Ifthereisnoconfigured
registraraddress,theUASHOULDusethehostpartoftheaddress
ofrecordastheRequestURIandaddresstherequestthere,usingthe
normalSIPserverlocationmechanisms[4].Forexample,theUAfor
theuser"sip:carol@chicago.com"addressestheREGISTERrequestto
"sip:chicago.com".
Finally,aUAcanbeconfiguredtousemulticast.Multicast
registrationsareaddressedtothewellknown"allSIPservers"
multicastaddress"sip.mcast.net"(224.0.1.75forIPv4).Nowell
knownIPv6multicastaddresshasbeenallocatedsuchanallocation
willbedocumentedseparatelywhenneeded.SIPUAsMAYlistento
thataddressanduseittobecomeawareofthelocationofother
localusers(see[33])however,theydonotrespondtotherequest.
Multicastregistrationmaybeinappropriateinsomeenvironments,
forexample,ifmultiplebusinessessharethesamelocalarea
network.
10.2.7TransmittingaRequest
OncetheREGISTERmethodhasbeenconstructed,andthedestinationof
themessageidentified,UACsfollowtheproceduresdescribedin
Section8.1.2tohandofftheREGISTERtothetransactionlayer.
IfthetransactionlayerreturnsatimeouterrorbecausetheREGISTER
yieldednoresponse,theUACSHOULDNOTimmediatelyreattempta
registrationtothesameregistrar.
Animmediatereattemptislikelytoalsotimeout.Waitingsome
reasonabletimeintervalfortheconditionscausingthetimeoutto
becorrectedreducesunnecessaryloadonthenetwork.Nospecific
intervalismandated.
10.2.8ErrorResponses
IfaUAreceivesa423(IntervalTooBrief)response,itMAYretry
theregistrationaftermakingtheexpirationintervalofallcontact
addressesintheREGISTERrequestequaltoorgreaterthanthe
expirationintervalwithintheMinExpiresheaderfieldofthe423
(IntervalTooBrief)response.
10.3ProcessingREGISTERRequests
AregistrarisaUASthatrespondstoREGISTERrequestsandmaintains
alistofbindingsthatareaccessibletoproxyserversandredirect
serverswithinitsadministrativedomain.Aregistrarhandles
requestsaccordingtoSection8.2andSection17.2,butitaccepts
onlyREGISTERrequests.AregistrarMUSTnotgenerate6xxresponses.
AregistrarMAYredirectREGISTERrequestsasappropriate.One
commonusagewouldbeforaregistrarlisteningonamulticast
interfacetoredirectmulticastREGISTERrequeststoitsownunicast
interfacewitha302(MovedTemporarily)response.
RegistrarsMUSTignoretheRecordRouteheaderfieldifitis
includedinaREGISTERrequest.RegistrarsMUSTNOTincludea
RecordRouteheaderfieldinanyresponsetoaREGISTERrequest.
Aregistrarmightreceivearequestthattraversedaproxywhich
treatsREGISTERasanunknownrequestandwhichaddedaRecord
Routeheaderfieldvalue.
Aregistrarhastoknow(forexample,throughconfiguration)theset
ofdomain(s)forwhichitmaintainsbindings.REGISTERrequestsMUST
beprocessedbyaregistrarintheorderthattheyarereceived.
REGISTERrequestsMUSTalsobeprocessedatomically,meaningthata
particularREGISTERrequestiseitherprocessedcompletelyornotat
all.EachREGISTERmessageMUSTbeprocessedindependentlyofany
otherregistrationorbindingchanges.
WhenreceivingaREGISTERrequest,aregistrarfollowsthesesteps:
1.TheregistrarinspectstheRequestURItodeterminewhetherit
hasaccesstobindingsforthedomainidentifiedinthe
RequestURI.Ifnot,andiftheserveralsoactsasaproxy
server,theserverSHOULDforwardtherequesttotheaddressed
domain,followingthegeneralbehaviorforproxyingmessages
describedinSection16.
2.Toguaranteethattheregistrarsupportsanynecessary
extensions,theregistrarMUSTprocesstheRequireheaderfield
valuesasdescribedforUASsinSection8.2.2.
3.AregistrarSHOULDauthenticatetheUAC.Mechanismsforthe
authenticationofSIPuseragentsaredescribedinSection22.
Registrationbehaviorinnowayoverridesthegeneric
authenticationframeworkforSIP.Ifnoauthentication
mechanismisavailable,theregistrarMAYtaketheFromaddress
astheassertedidentityoftheoriginatoroftherequest.
4.TheregistrarSHOULDdetermineiftheauthenticateduseris
authorizedtomodifyregistrationsforthisaddressofrecord.
Forexample,aregistrarmightconsultanauthorization
databasethatmapsusernamestoalistofaddressesofrecord
forwhichthatuserhasauthorizationtomodifybindings.If
theauthenticateduserisnotauthorizedtomodifybindings,
theregistrarMUSTreturna403(Forbidden)andskipthe
remainingsteps.
Inarchitecturesthatsupportthirdpartyregistration,one
entitymayberesponsibleforupdatingtheregistrations
associatedwithmultipleaddressesofrecord.
5.TheregistrarextractstheaddressofrecordfromtheToheader
fieldoftherequest.Iftheaddressofrecordisnotvalid
forthedomainintheRequestURI,theregistrarMUSTsenda
404(NotFound)responseandskiptheremainingsteps.TheURI
MUSTthenbeconvertedtoacanonicalform.Todothat,all
URIparametersMUSTberemoved(includingtheuserparam),and
anyescapedcharactersMUSTbeconvertedtotheirunescaped
form.Theresultservesasanindexintothelistofbindings.
6.TheregistrarcheckswhethertherequestcontainstheContact
headerfield.Ifnot,itskipstothelaststep.Ifthe
Contactheaderfieldispresent,theregistrarchecksifthere
isoneContactfieldvaluethatcontainsthespecialvalue"*"
andanExpiresfield.IftherequesthasadditionalContact
fieldsoranexpirationtimeotherthanzero,therequestis
invalid,andtheserverMUSTreturna400(InvalidRequest)and
skiptheremainingsteps.Ifnot,theregistrarcheckswhether
theCallIDagreeswiththevaluestoredforeachbinding.If
not,itMUSTremovethebinding.Ifitdoesagree,itMUST
removethebindingonlyiftheCSeqintherequestishigher
thanthevaluestoredforthatbinding.Otherwise,theupdate
MUSTbeabortedandtherequestfails.
7.TheregistrarnowprocesseseachcontactaddressintheContact
headerfieldinturn.Foreachaddress,itdeterminesthe
expirationintervalasfollows:
Ifthefieldvaluehasan"expires"parameter,thatvalue
MUSTbetakenastherequestedexpiration.
Ifthereisnosuchparameter,buttherequesthasan
Expiresheaderfield,thatvalueMUSTbetakenasthe
requestedexpiration.
Ifthereisneither,alocallyconfigureddefaultvalueMUST
betakenastherequestedexpiration.
TheregistrarMAYchooseanexpirationlessthantherequested
expirationinterval.Ifandonlyiftherequestedexpiration
intervalisgreaterthanzeroANDsmallerthanonehourAND
lessthanaregistrarconfiguredminimum,theregistrarMAY
rejecttheregistrationwitharesponseof423(IntervalToo
Brief).ThisresponseMUSTcontainaMinExpiresheaderfield
thatstatestheminimumexpirationintervaltheregistraris
willingtohonor.Itthenskipstheremainingsteps.
Allowingtheregistrartosettheregistrationinterval
protectsitagainstexcessivelyfrequentregistrationrefreshes
whilelimitingthestatethatitneedstomaintainand
decreasingthelikelihoodofregistrationsgoingstale.The
expirationintervalofaregistrationisfrequentlyusedinthe
creationofservices.Anexampleisafollowmeservice,where
theusermayonlybeavailableataterminalforabrief
period.Therefore,registrarsshouldacceptbrief
registrationsarequestshouldonlyberejectedifthe
intervalissoshortthattherefresheswoulddegraderegistrar
performance.
Foreachaddress,theregistrarthensearchesthelistof
currentbindingsusingtheURIcomparisonrules.Ifthe
bindingdoesnotexist,itistentativelyadded.Ifthe
bindingdoesexist,theregistrarcheckstheCallIDvalue.If
theCallIDvalueintheexistingbindingdiffersfromthe
CallIDvalueintherequest,thebindingMUSTberemovedif
theexpirationtimeiszeroandupdatedotherwise.Iftheyare
thesame,theregistrarcomparestheCSeqvalue.Ifthevalue
ishigherthanthatoftheexistingbinding,itMUSTupdateor
removethebindingasabove.Ifnot,theupdateMUSTbe
abortedandtherequestfails.
Thisalgorithmensuresthatoutoforderrequestsfromthesame
UAareignored.
EachbindingrecordrecordstheCallIDandCSeqvaluesfrom
therequest.
ThebindingupdatesMUSTbecommitted(thatis,madevisibleto
theproxyorredirectserver)ifandonlyifallbinding
updatesandadditionssucceed.Ifanyoneofthemfails(for
example,becausethebackenddatabasecommitfailed),the
requestMUSTfailwitha500(ServerError)responseandall
tentativebindingupdatesMUSTberemoved.
8.Theregistrarreturnsa200(OK)response.TheresponseMUST
containContactheaderfieldvaluesenumeratingallcurrent
bindings.EachContactvalueMUSTfeaturean"expires"
parameterindicatingitsexpirationintervalchosenbythe
registrar.TheresponseSHOULDincludeaDateheaderfield.
11QueryingforCapabilities
TheSIPmethodOPTIONSallowsaUAtoqueryanotherUAoraproxy
serverastoitscapabilities.Thisallowsaclienttodiscover
informationaboutthesupportedmethods,contenttypes,extensions,
codecs,etc.without"ringing"theotherparty.Forexample,before
aclientinsertsaRequireheaderfieldintoanINVITElistingan
optionthatitisnotcertainthedestinationUASsupports,the
clientcanquerythedestinationUASwithanOPTIONStoseeifthis
optionisreturnedinaSupportedheaderfield.AllUAsMUSTsupport
theOPTIONSmethod.
ThetargetoftheOPTIONSrequestisidentifiedbytheRequestURI,
whichcouldidentifyanotherUAoraSIPserver.IftheOPTIONSis
addressedtoaproxyserver,theRequestURIissetwithoutauser
part,similartothewayaRequestURIissetforaREGISTERrequest.
Alternatively,aserverreceivinganOPTIONSrequestwithaMax
Forwardsheaderfieldvalueof0MAYrespondtotherequest
regardlessoftheRequestURI.
ThisbehavioriscommonwithHTTP/1.1.Thisbehaviorcanbeused
asa"traceroute"functionalitytocheckthecapabilitiesof
individualhopserversbysendingaseriesofOPTIONSrequests
withincrementedMaxForwardsvalues.
AsisthecaseforgeneralUAbehavior,thetransactionlayercan
returnatimeouterroriftheOPTIONSyieldsnoresponse.Thismay
indicatethatthetargetisunreachableandhenceunavailable.
AnOPTIONSrequestMAYbesentaspartofanestablisheddialogto
querythepeeroncapabilitiesthatmaybeutilizedlaterinthe
dialog.
11.1ConstructionofOPTIONSRequest
AnOPTIONSrequestisconstructedusingthestandardrulesforaSIP
requestasdiscussedinSection8.1.1.
AContactheaderfieldMAYbepresentinanOPTIONS.
AnAcceptheaderfieldSHOULDbeincludedtoindicatethetypeof
messagebodytheUACwishestoreceiveintheresponse.Typically,
thisissettoaformatthatisusedtodescribethemedia
capabilitiesofaUA,suchasSDP(application/sdp).
TheresponsetoanOPTIONSrequestisassumedtobescopedtothe
RequestURIintheoriginalrequest.However,onlywhenanOPTIONS
issentaspartofanestablisheddialogisitguaranteedthatfuture
requestswillbereceivedbytheserverthatgeneratedtheOPTIONS
response.
ExampleOPTIONSrequest:
OPTIONSsip:carol@chicago.comSIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bKhjhs8ass877
MaxForwards:70
To:<sip:carol@chicago.com>
CallID:a84b4c76e66710
CSeq:63104OPTIONS
Accept:application/sdp
ContentLength:0
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
treatedbyproxiesusingthenonINVITEhandling.SeeSection16.7
forthenormativedetails.
IftheresponsetoanOPTIONSisgeneratedbyaproxyserver,the
proxyreturnsa200(OK),listingthecapabilitiesoftheserver.
Theresponsedoesnotcontainamessagebody.
Allow,Accept,AcceptEncoding,AcceptLanguage,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].
ExampleOPTIONSresponsegeneratedbyaUAS(correspondingtothe
requestinSection11.1):
SIP/2.0200OK
Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bKhjhs8ass877
received=192.0.2.4
To:<sip:carol@chicago.com>tag=93810874
CSeq:63104OPTIONS
Contact:<sip:carol@chicago.com>
Contact:<mailto:carol@chicago.com>
Allow:INVITE,ACK,CANCEL,OPTIONS,BYE
Accept:application/sdp
AcceptEncoding:gzip
AcceptLanguage:en
Supported:foo
ContentLength:274
(SDPnotshown)
12Dialogs
Akeyconceptforauseragentisthatofadialog.Adialog
representsapeertopeerSIPrelationshipbetweentwouseragents
thatpersistsforsometime.Thedialogfacilitatessequencingof
messagesbetweentheuseragentsandproperroutingofrequests
betweenbothofthem.Thedialogrepresentsacontextinwhichto
interpretSIPmessages.Section8discussedmethodindependentUA
processingforrequestsandresponsesoutsideofadialog.This
sectiondiscusseshowthoserequestsandresponsesareusedto
constructadialog,andthenhowsubsequentrequestsandresponses
aresentwithinadialog.
AdialogisidentifiedateachUAwithadialogID,whichconsistsof
aCallIDvalue,alocaltagandaremotetag.ThedialogIDateach
UAinvolvedinthedialogisnotthesame.Specifically,thelocal
tagatoneUAisidenticaltotheremotetagatthepeerUA.The
tagsareopaquetokensthatfacilitatethegenerationofunique
dialogIDs.
AdialogIDisalsoassociatedwithallresponsesandwithany
requestthatcontainsatagintheTofield.Therulesforcomputing
thedialogIDofamessagedependonwhethertheSIPelementisaUAC
orUAS.ForaUAC,theCallIDvalueofthedialogIDissettothe
CallIDofthemessage,theremotetagissettothetagintheTo
fieldofthemessage,andthelocaltagissettothetagintheFrom
fieldofthemessage(theserulesapplytobothrequestsand
responses).AsonewouldexpectforaUAS,theCallIDvalueofthe
dialogIDissettotheCallIDofthemessage,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
Dialogsarecreatedthroughthegenerationofnonfailureresponses
torequestswithspecificmethods.Withinthisspecification,only
2xxand101199responseswithaTotag,wheretherequestwas
INVITE,willestablishadialog.Adialogestablishedbyanonfinal
responsetoarequestisinthe"early"stateanditiscalledan
earlydialog.ExtensionsMAYdefineothermeansforcreating
dialogs.Section13givesmoredetailsthatarespecifictothe
INVITEmethod.Here,wedescribetheprocessforcreationofdialog
statethatisnotdependentonthemethod.
UAsMUSTassignvaluestothedialogIDcomponentsasdescribed
below.
12.1.1UASbehavior
WhenaUASrespondstoarequestwitharesponsethatestablishesa
dialog(suchasa2xxtoINVITE),theUASMUSTcopyallRecordRoute
headerfieldvaluesfromtherequestintotheresponse(includingthe
URIs,URIparameters,andanyRecordRouteheaderfieldparameters,
whethertheyareknownorunknowntotheUAS)andMUSTmaintainthe
orderofthosevalues.TheUASMUSTaddaContactheaderfieldto
theresponse.TheContactheaderfieldcontainsanaddresswherethe
UASwouldliketobecontactedforsubsequentrequestsinthedialog
(whichincludestheACKfora2xxresponseinthecaseofanINVITE).
Generally,thehostportionofthisURIistheIPaddressorFQDNof
thehost.TheURIprovidedintheContactheaderfieldMUSTbeaSIP
orSIPSURI.Iftherequestthatinitiatedthedialogcontaineda
SIPSURIintheRequestURIorinthetopRecordRouteheaderfield
value,iftherewasany,ortheContactheaderfieldiftherewasno
RecordRouteheaderfield,theContactheaderfieldintheresponse
MUSTbeaSIPSURI.TheURISHOULDhaveglobalscope(thatis,the
sameURIcanbeusedinmessagesoutsidethisdialog).Thesameway,
thescopeoftheURIintheContactheaderfieldoftheINVITEisnot
limitedtothisdialogeither.Itcanthereforebeusedinmessages
totheUACevenoutsidethisdialog.
TheUASthenconstructsthestateofthedialog.ThisstateMUSTbe
maintainedforthedurationofthedialog.
IftherequestarrivedoverTLS,andtheRequestURIcontainedaSIPS
URI,the"secure"flagissettoTRUE.
TheroutesetMUSTbesettothelistofURIsintheRecordRoute
headerfieldfromtherequest,takeninorderandpreservingallURI
parameters.IfnoRecordRouteheaderfieldispresentinthe
request,theroutesetMUSTbesettotheemptyset.Thisrouteset,
evenifempty,overridesanypreexistingroutesetforfuture
requestsinthisdialog.TheremotetargetMUSTbesettotheURI
fromtheContactheaderfieldoftherequest.
TheremotesequencenumberMUSTbesettothevalueofthesequence
numberintheCSeqheaderfieldoftherequest.Thelocalsequence
numberMUSTbeempty.ThecallidentifiercomponentofthedialogID
MUSTbesettothevalueoftheCallIDintherequest.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.
WhenaUACreceivesaresponsethatestablishesadialog,it
constructsthestateofthedialog.ThisstateMUSTbemaintained
forthedurationofthedialog.
IftherequestwassentoverTLS,andtheRequestURIcontaineda
SIPSURI,the"secure"flagissettoTRUE.
TheroutesetMUSTbesettothelistofURIsintheRecordRoute
headerfieldfromtheresponse,takeninreverseorderandpreserving
allURIparameters.IfnoRecordRouteheaderfieldispresentin
theresponse,theroutesetMUSTbesettotheemptyset.Thisroute
set,evenifempty,overridesanypreexistingroutesetforfuture
requestsinthisdialog.TheremotetargetMUSTbesettotheURI
fromtheContactheaderfieldoftheresponse.
ThelocalsequencenumberMUSTbesettothevalueofthesequence
numberintheCSeqheaderfieldoftherequest.Theremotesequence
numberMUSTbeempty(itisestablishedwhentheremoteUAsendsa
requestwithinthedialog).Thecallidentifiercomponentofthe
dialogIDMUSTbesettothevalueoftheCallIDintherequest.
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.
RequestswithinadialogMAYcontainRecordRouteandContactheader
fields.However,theserequestsdonotcausethedialog'srouteset
tobemodified,althoughtheymaymodifytheremotetargetURI.
Specifically,requeststhatarenottargetrefreshrequestsdonot
modifythedialog'sremotetargetURI,andrequeststhataretarget
refreshrequestsdo.Fordialogsthathavebeenestablishedwithan
INVITE,theonlytargetrefreshrequestdefinedisreINVITE(see
Section14).Otherextensionsmaydefinedifferenttargetrefresh
requestsfordialogsestablishedinotherways.
NotethatanACKisNOTatargetrefreshrequest.
Targetrefreshrequestsonlyupdatethedialog'sremotetargetURI,
andnottheroutesetformedfromtheRecordRoute.Updatingthe
latterwouldintroduceseverebackwardscompatibilityproblemswith
RFC2543compliantsystems.
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
oftheoriginalToandFromURIinmiddialogrequestswillbe
deprecatedinasubsequentrevisionofthisspecification.
TheCallIDoftherequestMUSTbesettotheCallIDofthedialog.
RequestswithinadialogMUSTcontainstrictlymonotonically
increasingandcontiguousCSeqsequencenumbers(increasingbyone)
ineachdirection(exceptingACKandCANCELofcourse,whosenumbers
equaltherequestsbeingacknowledgedorcancelled).Therefore,if
thelocalsequencenumberisnotempty,thevalueofthelocal
sequencenumberMUSTbeincrementedbyone,andthisvalueMUSTbe
placedintotheCSeqheaderfield.Ifthelocalsequencenumberis
empty,aninitialvalueMUSTbechosenusingtheguidelinesof
Section8.1.1.5.ThemethodfieldintheCSeqheaderfieldvalue
MUSTmatchthemethodoftherequest.
Withalengthof32bits,aclientcouldgenerate,withinasingle
call,onerequestasecondforabout136yearsbeforeneedingto
wraparound.Theinitialvalueofthesequencenumberischosen
sothatsubsequentrequestswithinthesamecallwillnotwrap
around.Anonzeroinitialvalueallowsclientstouseatime
basedinitialsequencenumber.Aclientcould,forexample,
choosethe31mostsignificantbitsofa32bitsecondclockasan
initialsequencenumber.
TheUACusestheremotetargetandroutesettobuildtheRequestURI
andRouteheaderfieldoftherequest.
Iftheroutesetisempty,theUACMUSTplacetheremotetargetURI
intotheRequestURI.TheUACMUSTNOTaddaRouteheaderfieldto
therequest.
Iftheroutesetisnotempty,andthefirstURIintherouteset
containsthelrparameter(seeSection19.1.1),theUACMUSTplace
theremotetargetURIintotheRequestURIandMUSTincludeaRoute
headerfieldcontainingtheroutesetvaluesinorder,includingall
parameters.
Iftheroutesetisnotempty,anditsfirstURIdoesnotcontainthe
lrparameter,theUACMUSTplacethefirstURIfromtherouteset
intotheRequestURI,strippinganyparametersthatarenotallowed
inaRequestURI.TheUACMUSTaddaRouteheaderfieldcontaining
theremainderoftheroutesetvaluesinorder,includingall
parameters.TheUACMUSTthenplacetheremotetargetURIintothe
Routeheaderfieldasthelastvalue.
Forexample,iftheremotetargetissip:user@remoteuaandtheroute
setcontains:
<sip:proxy1>,<sip:proxy2>,<sip:proxy3lr>,<sip:proxy4>
TherequestwillbeformedwiththefollowingRequestURIandRoute
headerfield:
METHODsip:proxy1
Route:<sip:proxy2>,<sip:proxy3lr>,<sip:proxy4>,<sip:user@remoteua>
IfthefirstURIoftheroutesetdoesnotcontainthelr
parameter,theproxyindicateddoesnotunderstandtherouting
mechanismsdescribedinthisdocumentandwillactasspecifiedin
RFC2543,replacingtheRequestURIwiththefirstRouteheader
fieldvalueitreceiveswhileforwardingthemessage.Placingthe
RequestURIattheendoftheRouteheaderfieldpreservesthe
informationinthatRequestURIacrossthestrictrouter(itwill
bereturnedtotheRequestURIwhentherequestreachesaloose
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
headerfieldvalueortheRequestURIifnoRouteheaderfieldis
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.
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,thisisamiddialogrequest.
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,andacceptingoutofrangeRTPtimestampsandsequence
numbers.
IftheUASwishestorejecttherequestbecauseitdoesnotwishto
recreatethedialog,itMUSTrespondtotherequestwitha481
(Call/TransactionDoesNotExist)statuscodeandpassthattothe
servertransaction.
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
anon2xxfinalresponse,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
invitation.Aftersometime,thoseUASscanaccepttheinvitation
(meaningthesessionistobeestablished)bysendinga2xxresponse.
Iftheinvitationisnotaccepted,a3xx,4xx,5xxor6xxresponseis
sent,dependingonthereasonfortherejection.Beforesendinga
finalresponse,theUAScanalsosendprovisionalresponses(1xx)to
advisetheUACofprogressincontactingthecalleduser.
Afterpossiblyreceivingoneormoreprovisionalresponses,theUAC
willgetoneormore2xxresponsesoronenon2xxfinalresponse.
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.
AnAccept(Section20.1)headerfieldMAYbepresentintheINVITE.
ItindicateswhichContentTypesareacceptabletotheUA,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)andUserAgent(Section20.41)
headerfields.TheyallcontaininformationrelatedtotheINVITE.
TheUACMAYchoosetoaddamessagebodytotheINVITE.Section
8.1.1.10dealswithhowtoconstructtheheaderfieldsContent
Typeamongothersneededtodescribethemessagebody.
Therearespecialrulesformessagebodiesthatcontainasession
descriptiontheircorrespondingContentDispositionis"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,
inthefirstreliablenonfailuremessagefromtheUASbackto
theUAC.Inthisspecification,thatisthefinal2xx
response.
oIftheinitialofferisinanINVITE,theanswerMUSTbeina
reliablenonfailuremessagefromUASbacktoUACwhichis
correlatedtothatINVITE.Forthisspecification,thatis
onlythefinal2xxresponsetothatINVITE.Thatsameexact
answerMAYalsobeplacedinanyprovisionalresponsessent
priortotheanswer.TheUACMUSTtreatthefirstsession
descriptionitreceivesastheanswer,andMUSTignoreany
sessiondescriptionsinsubsequentresponsestotheinitial
INVITE.
oIftheinitialofferisinthefirstreliablenonfailure
messagefromtheUASbacktoUAC,theanswerMUSTbeinthe
acknowledgementforthatmessage(inthisspecification,ACK
fora2xxresponse).
oAfterhavingsentorreceivedananswertothefirstoffer,the
UACMAYgeneratesubsequentoffersinrequestsbasedonrules
specifiedforthatmethod,butonlyifithasreceivedanswers
toanypreviousoffers,andhasnotsentanyofferstowhichit
hasn'tgottenananswer.
oOncetheUAShassentorreceivedananswertotheinitial
offer,itMUSTNOTgeneratesubsequentoffersinanyresponses
totheinitialINVITE.ThismeansthataUASbasedonthis
specificationalonecannevergeneratesubsequentoffersuntil
completionoftheinitialtransaction.
Concretely,theaboverulesspecifytwoexchangesforUAscompliant
tothisspecificationalonetheofferisintheINVITE,andthe
answerinthe2xx(andpossiblyina1xxaswell,withthesame
value),ortheofferisinthe2xx,andtheanswerisintheACK.
AlluseragentsthatsupportINVITEMUSTsupportthesetwoexchanges.
TheSessionDescriptionProtocol(SDP)(RFC2327[1])MUSTbe
supportedbyalluseragentsasameanstodescribesessions,andits
usageforconstructingoffersandanswersMUSTfollowtheprocedures
definedin[13].
Therestrictionsoftheofferanswermodeljustdescribedonlyapply
tobodieswhoseContentDispositionheaderfieldvalueis"session".
Therefore,itispossiblethatboththeINVITEandtheACKcontaina
bodymessage(forexample,theINVITEcarriesaphoto(Content
Disposition:render)andtheACKasessiondescription(Content
Disposition:session)).
IftheContentDispositionheaderfieldismissing,bodiesof
ContentTypeapplication/sdpimplythedisposition"session",while
othercontenttypesimply"render".
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).
A3xxresponsemaycontainoneormoreContactheaderfieldvalues
providingnewaddresseswherethecalleemightbereachable.
Dependingonthestatuscodeofthe3xxresponse(seeSection21.3),
theUACMAYchoosetotrythosenewaddresses.
13.2.2.34xx,5xxand6xxResponses
Asinglenon2xxfinalresponsemaybereceivedfortheINVITE.4xx,
5xxand6xxresponsesmaycontainaContactheaderfieldvalue
indicatingthelocationwhereadditionalinformationabouttheerror
canbefound.Subsequentfinalresponses(whichwouldonlyarrive
undererrorconditions)MUSTbeignored.
Allearlydialogsareconsideredterminateduponreceptionofthe
non2xxfinalresponse.
Afterhavingreceivedthenon2xxfinalresponsetheUACcore
considerstheINVITEtransactioncompleted.TheINVITEclient
transactionhandlesthegenerationofACKsfortheresponse(see
Section17).
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
2543didnotmandatemirroringoftheRecordRouteheaderfieldin
a1xx,only2xx.However,wecannotupdatetheentirestateof
thedialog,sincemiddialogrequestsmayhavebeensentwithin
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.
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.Iftherequestisamiddialogrequest,themethodindependent
processingdescribedinSection12.2.2isfirstapplied.It
mightalsomodifythesessionSection14providesdetails.
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
containsasessionidandversionnumberintheorigin(o)field.If
theuserisalreadyamemberofthesession,andthesession
parameterscontainedinthesessiondescriptionhavenotchanged,the
UASMAYsilentlyaccepttheINVITE(thatis,senda2xxresponse
withoutpromptingtheuser).
IftheINVITEdoesnotcontainasessiondescription,theUASis
beingaskedtoparticipateinasession,andtheUAChasaskedthat
theUASprovidetheofferofthesession.ItMUSTprovidetheoffer
initsfirstnonfailurereliablemessagebacktotheUAC.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,theUASMUSTsendanon100
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
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.
Since2xxisretransmittedendtoend,theremaybehopsbetween
UASandUACthatareUDP.Toensurereliabledeliveryacross
thesehops,theresponseisretransmittedperiodicallyevenifthe
transportattheUASisreliable.
Iftheserverretransmitsthe2xxresponsefor64*T1secondswithout
receivinganACK,thedialogisconfirmed,butthesessionSHOULDbe
terminated.ThisisaccomplishedwithaBYE,asdescribedinSection
15.
14ModifyinganExistingSession
AsuccessfulINVITErequest(seeSection13)establishesbotha
dialogbetweentwouseragentsandasessionusingtheofferanswer
model.Section12explainshowtomodifyanexistingdialogusinga
targetrefreshrequest(forexample,changingtheremotetargetURI
ofthedialog).Thissectiondescribeshowtomodifytheactual
session.Thismodificationcaninvolvechangingaddressesorports,
addingamediastream,deletingamediastream,andsoon.Thisis
accomplishedbysendinganewINVITErequestwithinthesamedialog
thatestablishedthesession.AnINVITErequestsentwithinan
existingdialogisknownasareINVITE.
NotethatasinglereINVITEcanmodifythedialogandthe
parametersofthesessionatthesametime.
Eitherthecallerorcalleecanmodifyanexistingsession.
ThebehaviorofaUAondetectionofmediafailureisamatterof
localpolicy.However,automatedgenerationofreINVITEorBYEis
NOTRECOMMENDEDtoavoidfloodingthenetworkwithtrafficwhenthere
iscongestion.Inanycase,ifthesemessagesaresent
automatically,theySHOULDbesentaftersomerandomizedinterval.
Notethattheparagraphabovereferstoautomaticallygenerated
BYEsandreINVITEs.Iftheuserhangsupuponmediafailure,the
UAwouldsendaBYErequestasusual.
14.1UACBehavior
Thesameofferanswermodelthatappliestosessiondescriptionsin
INVITEs(Section13.2.1)appliestoreINVITEs.Asaresult,aUAC
thatwantstoaddamediastream,forexample,willcreateanew
offerthatcontainsthismediastream,andsendthatinanINVITE
requesttoitspeer.Itisimportanttonotethatthefull
descriptionofthesession,notjustthechange,issent.This
supportsstatelesssessionprocessinginvariouselements,and
supportsfailoverandrecoverycapabilities.Ofcourse,aUACMAY
sendareINVITEwithnosessiondescription,inwhichcasethefirst
reliablenonfailureresponsetothereINVITEwillcontaintheoffer
(inthisspecification,thatisa2xxresponse).
Ifthesessiondescriptionformathasthecapabilityforversion
numbers,theoffererSHOULDindicatethattheversionofthesession
descriptionhaschanged.
TheTo,From,CallID,CSeq,andRequestURIofareINVITEareset
followingthesamerulesasforregularrequestswithinanexisting
dialog,describedinSection12.
AUACMAYchoosenottoaddanAlertInfoheaderfieldorabodywith
ContentDisposition"alert"toreINVITEsbecauseUASsdonot
typicallyalerttheuseruponreceptionofareINVITE.
UnlikeanINVITE,whichcanfork,areINVITEwillneverfork,and
therefore,onlyevergenerateasinglefinalresponse.Thereasona
reINVITEwillneverforkisthattheRequestURIidentifiesthe
targetastheUAinstanceitestablishedthedialogwith,ratherthan
identifyinganaddressofrecordfortheuser.
NotethataUACMUSTNOTinitiateanewINVITEtransactionwithina
dialogwhileanotherINVITEtransactionisinprogressineither
direction.
1.IfthereisanongoingINVITEclienttransaction,theTUMUST
waituntilthetransactionreachesthecompletedorterminated
statebeforeinitiatingthenewINVITE.
2.IfthereisanongoingINVITEservertransaction,theTUMUST
waituntilthetransactionreachestheconfirmedorterminated
statebeforeinitiatingthenewINVITE.
However,aUAMAYinitiatearegulartransactionwhileanINVITE
transactionisinprogress.AUAMAYalsoinitiateanINVITE
transactionwhilearegulartransactionisinprogress.
IfaUAreceivesanon2xxfinalresponsetoareINVITE,thesession
parametersMUSTremainunchanged,asifnoreINVITEhadbeenissued.
Notethat,asstatedinSection12.2.1.2,ifthenon2xxfinal
responseisa481(Call/TransactionDoesNotExist),ora408
(RequestTimeout),ornoresponseatallisreceivedforthere
INVITE(thatis,atimeoutisreturnedbytheINVITEclient
transaction),theUACwillterminatethedialog.
IfaUACreceivesa491responsetoareINVITE,itSHOULDstarta
timerwithavalueTchosenasfollows:
1.IftheUACistheowneroftheCallIDofthedialogID
(meaningitgeneratedthevalue),Thasarandomlychosenvalue
between2.1and4secondsinunitsof10ms.
2.IftheUACisnottheowneroftheCallIDofthedialogID,T
hasarandomlychosenvalueofbetween0and2secondsinunits
of10ms.
Whenthetimerfires,theUACSHOULDattemptthereINVITEoncemore,
ifitstilldesiresforthatsessionmodificationtotakeplace.For
example,ifthecallwasalreadyhungupwithaBYE,thereINVITE
wouldnottakeplace.
TherulesfortransmittingareINVITEandforgeneratinganACKfor
a2xxresponsetoreINVITEarethesameasfortheinitialINVITE
(Section13.2.1).
14.2UASBehavior
Section13.3.1describestheprocedurefordistinguishingincoming
reINVITEsfromincominginitialINVITEsandhandlingareINVITEfor
anexistingdialog.
AUASthatreceivesasecondINVITEbeforeitsendsthefinal
responsetoafirstINVITEwithalowerCSeqsequencenumberonthe
samedialogMUSTreturna500(ServerInternalError)responsetothe
secondINVITEandMUSTincludeaRetryAfterheaderfieldwitha
randomlychosenvalueofbetween0and10seconds.
AUASthatreceivesanINVITEonadialogwhileanINVITEithadsent
onthatdialogisinprogressMUSTreturna491(RequestPending)
responsetothereceivedINVITE.
IfaUAreceivesareINVITEforanexistingdialog,itMUSTcheck
anyversionidentifiersinthesessiondescriptionor,ifthereare
noversionidentifiers,thecontentofthesessiondescriptiontosee
ifithaschanged.Ifthesessiondescriptionhaschanged,theUAS
MUSTadjustthesessionparametersaccordingly,possiblyafterasking
theuserforconfirmation.
Versioningofthesessiondescriptioncanbeusedtoaccommodate
thecapabilitiesofnewarrivalstoaconference,addordelete
media,orchangefromaunicasttoamulticastconference.
Ifthenewsessiondescriptionisnotacceptable,theUAScanreject
itbyreturninga488(NotAcceptableHere)responseforthere
INVITE.ThisresponseSHOULDincludeaWarningheaderfield.
IfaUASgeneratesa2xxresponseandneverreceivesanACK,it
SHOULDgenerateaBYEtoterminatethedialog.
AUASMAYchoosenottogenerate180(Ringing)responsesforare
INVITEbecauseUACsdonottypicallyrenderthisinformationtothe
user.Forthesamereason,UASsMAYchoosenottouseanAlertInfo
headerfieldorabodywithContentDisposition"alert"inresponses
toareINVITE.
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"
withasingledialogtheonewhichresultedinitscreation.Ifan
initialINVITEgeneratesanon2xxfinalresponse,thatterminates
allsessions(ifany)andalldialogs(ifany)thatwerecreated
throughresponsestotherequest.Byvirtueofcompletingthe
transaction,anon2xxfinalresponsealsopreventsfurthersessions
frombeingcreatedasaresultoftheINVITE.TheBYErequestis
usedtoterminateaspecificsessionorattemptedsession.Inthis
case,thespecificsessionistheonewiththepeerUAontheother
sideofthedialog.WhenaBYEisreceivedonadialog,anysession
associatedwiththatdialogSHOULDterminate.AUAMUSTNOTsenda
BYEoutsideofadialog.Thecaller'sUAMAYsendaBYEforeither
confirmedorearlydialogs,andthecallee'sUAMAYsendaBYEon
confirmeddialogs,butMUSTNOTsendaBYEonearlydialogs.
However,thecallee'sUAMUSTNOTsendaBYEonaconfirmeddialog
untilithasreceivedanACKforits2xxresponseoruntiltheserver
transactiontimesout.IfnoSIPextensionshavedefinedother
applicationlayerstatesassociatedwiththedialog,theBYEalso
terminatesthedialog.
Theimpactofanon2xxfinalresponsetoINVITEondialogsand
sessionsmakestheuseofCANCELattractive.TheCANCELattemptsto
forceanon2xxresponsetotheINVITE(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,theUACcorecreatesanewnonINVITE
clienttransaction,andpassesittheBYErequest.TheUACMUST
considerthesessionterminated(andthereforestopsendingor
listeningformedia)assoonastheBYErequestispassedtothe
clienttransaction.IftheresponsefortheBYEisa481
(Call/TransactionDoesNotExist)ora408(RequestTimeout)orno
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
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)withoutbeingtransactionstateful.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
transaction.Requestsfromtheservertransactionarepassedtoa
proxycore.Theproxycoredetermineswheretoroutetherequest,
choosingoneormorenexthoplocations.Anoutgoingrequestfor
eachnexthoplocationisprocessedbyitsownassociatedclient
transaction.Theproxycorecollectstheresponsesfromtheclient
transactionsandusesthemtosendresponsestotheserver
transaction.
Astatefulproxycreatesanewservertransactionforeachnew
requestreceived.Anyretransmissionsoftherequestwillthenbe
handledbythatservertransactionperSection17.Theproxycore
MUSTbehaveasaUASwithrespecttosendinganimmediateprovisional
onthatservertransaction(suchas100Trying)asdescribedin
Section8.2.6.Thus,astatefulproxySHOULDNOTgenerate100
(Trying)responsestononINVITErequests.
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
4.Forwardtherequesttoeachtarget(Section16.6)
5.Processallresponses(Section16.7)
16.3RequestValidation
Beforeanelementcanproxyarequest,itMUSTverifythemessage's
validity.Avalidmessagemustpassthefollowingchecks:
1.ReasonableSyntax
2.URIscheme
3.MaxForwards
4.(Optional)LoopDetection
5.ProxyRequire
6.ProxyAuthorization
Ifanyofthesechecksfail,theelementMUSTbehaveasauseragent
server(seeSection8.2)andrespondwithanerrorcode.
Noticethataproxyisnotrequiredtodetectmergedrequestsand
MUSTNOTtreatmergedrequestsasanerrorcondition.Theendpoints
receivingtherequestswillresolvethemergeasdescribedinSection
8.2.2.2.
1.Reasonablesyntaxcheck
TherequestMUSTbewellformedenoughtobehandledwithaserver
transaction.Anycomponentsinvolvedintheremainderofthese
RequestValidationstepsortheRequestForwardingsectionMUSTbe
wellformed.Anyothercomponents,wellformedornot,SHOULDbe
ignoredandremainunchangedwhenthemessageisforwarded.For
instance,anelementwouldnotrejectarequestbecauseofa
malformedDateheaderfield.Likewise,aproxywouldnotremovea
malformedDateheaderfieldbeforeforwardingarequest.
Thisprotocolisdesignedtobeextended.Futureextensionsmay
definenewmethodsandheaderfieldsatanytime.AnelementMUST
NOTrefusetoproxyarequestbecauseitcontainsamethodor
headerfielditdoesnotknowabout.
2.URIschemecheck
IftheRequestURIhasaURIwhoseschemeisnotunderstoodbythe
proxy,theproxySHOULDrejecttherequestwitha416(Unsupported
URIScheme)response.
3.MaxForwardscheck
TheMaxForwardsheaderfield(Section20.22)isusedtolimitthe
numberofelementsaSIPrequestcantraverse.
IftherequestdoesnotcontainaMaxForwardsheaderfield,this
checkispassed.
IftherequestcontainsaMaxForwardsheaderfieldwithafield
valuegreaterthanzero,thecheckispassed.
IftherequestcontainsaMaxForwardsheaderfieldwithafield
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.ProxyRequirecheck
Futureextensionstothisprotocolmayintroducefeaturesthat
requirespecialhandlingbyproxies.Endpointswillincludea
ProxyRequireheaderfieldinrequeststhatusethesefeatures,
tellingtheproxynottoprocesstherequestunlessthefeatureis
understood.
IftherequestcontainsaProxyRequireheaderfield(Section
20.29)withoneormoreoptiontagsthiselementdoesnot
understand,theelementMUSTreturna420(BadExtension)
response.TheresponseMUSTincludeanUnsupported(Section
20.40)headerfieldlistingthoseoptiontagstheelementdidnot
understand.
6.ProxyAuthorizationcheck
Ifanelementrequirescredentialsbeforeforwardingarequest,
therequestMUSTbeinspectedasdescribedinSection22.3.That
sectionalsodefineswhattheelementmustdoiftheinspection
fails.
16.4RouteInformationPreprocessing
TheproxyMUSTinspecttheRequestURIoftherequest.Ifthe
RequestURIoftherequestcontainsavaluethisproxypreviously
placedintoaRecordRouteheaderfield(seeSection16.6item4),
theproxyMUSTreplacetheRequestURIintherequestwiththelast
valuefromtheRouteheaderfield,andremovethatvaluefromthe
Routeheaderfield.TheproxyMUSTthenproceedasifitreceived
thismodifiedrequest.
Thiswillonlyhappenwhentheelementsendingtherequesttothe
proxy(whichmayhavebeenanendpoint)isastrictrouter.This
rewriteonreceiveisnecessarytoenablebackwardscompatibility
withthoseelements.Italsoallowselementsfollowingthis
specificationtopreservetheRequestURIthroughstrictrouting
proxies(seeSection12.2.1.1).
Thisrequirementdoesnotobligateaproxytokeepstateinorder
todetectURIsitpreviouslyplacedinRecordRouteheaderfields.
Instead,aproxyneedonlyplaceenoughinformationinthoseURIs
torecognizethemasvaluesitprovidedwhentheylaterappear.
IftheRequestURIcontainsamaddrparameter,theproxyMUSTcheck
toseeifitsvalueisinthesetofaddressesordomainstheproxy
isconfiguredtoberesponsiblefor.IftheRequestURIhasamaddr
parameterwithavaluetheproxyisresponsiblefor,andtherequest
wasreceivedusingtheportandtransportindicated(explicitlyorby
default)intheRequestURI,theproxyMUSTstripthemaddrandany
nondefaultportortransportparameterandcontinueprocessingasif
thosevalueshadnotbeenpresentintherequest.
Arequestmayarrivewithamaddrmatchingtheproxy,butona
portortransportdifferentfromthatindicatedintheURI.Such
arequestneedstobeforwardedtotheproxyusingtheindicated
portandtransport.
IfthefirstvalueintheRouteheaderfieldindicatesthisproxy,
theproxyMUSTremovethatvaluefromtherequest.
16.5DeterminingRequestTargets
Next,theproxycalculatesthetarget(s)oftherequest.Thesetof
targetswilleitherbepredeterminedbythecontentsoftherequest
orwillbeobtainedfromanabstractlocationservice.Eachtarget
inthesetisrepresentedasaURI.
IftheRequestURIoftherequestcontainsanmaddrparameter,the
RequestURIMUSTbeplacedintothetargetsetastheonlytarget
URI,andtheproxyMUSTproceedtoSection16.6.
IfthedomainoftheRequestURIindicatesadomainthiselementis
notresponsiblefor,theRequestURIMUSTbeplacedintothetarget
setastheonlytarget,andtheelementMUSTproceedtothetaskof
RequestForwarding(Section16.6).
Therearemanycircumstancesinwhichaproxymightreceivea
requestforadomainitisnotresponsiblefor.Afirewallproxy
handlingoutgoingcalls(thewayHTTPproxieshandleoutgoing
requests)isanexampleofwherethisislikelytooccur.
Ifthetargetsetfortherequesthasnotbeenpredeterminedas
describedabove,thisimpliesthattheelementisresponsibleforthe
domainintheRequestURI,andtheelementMAYusewhatevermechanism
itdesirestodeterminewheretosendtherequest.Anyofthese
mechanismscanbemodeledasaccessinganabstractLocationService.
Thismayconsistofobtaininginformationfromalocationservice
createdbyaSIPRegistrar,readingadatabase,consultingapresence
server,utilizingotherprotocols,orsimplyperformingan
algorithmicsubstitutionontheRequestURI.Whenaccessingthe
locationserviceconstructedbyaregistrar,theRequestURIMUST
firstbecanonicalizedasdescribedinSection10.3beforebeingused
asanindex.Theoutputofthesemechanismsisusedtoconstructthe
targetset.
IftheRequestURIdoesnotprovidesufficientinformationforthe
proxytodeterminethetargetset,itSHOULDreturna485(Ambiguous)
response.ThisresponseSHOULDcontainaContactheaderfield
containingURIsofnewaddressestobetried.Forexample,anINVITE
tosip:John.Smith@company.commaybeambiguousataproxywhose
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
RequestURIoftheoriginalrequestdoesnotindicatearesourcethis
proxyisresponsiblefor.
AproxycanonlychangetheRequestURIofarequestduring
forwardingifitisresponsibleforthatURI.Iftheproxyisnot
responsibleforthatURI,itwillnotrecurseon3xxor416
responsesasdescribedbelow.
IftheRequestURIoftheoriginalrequestindicatesaresourcethis
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"noop",wherethe
targetURIisequaltotheincomingrequestURI.Therequestissent
toaspecificnexthopproxyforfurtherprocessing.Duringrequest
forwardingofSection16.6,Item6,theidentityofthatnexthop,
expressedasaSIPorSIPSURI,isinsertedasthetopmostRoute
headerfieldvalueintotherequest.
IftheRequestURIindicatesaresourceatthisproxythatdoesnot
exist,theproxyMUSTreturna404(NotFound)response.
Ifthetargetsetremainsemptyafterapplyingalloftheabove,the
proxyMUSTreturnanerrorresponse,whichSHOULDbethe480
(TemporarilyUnavailable)response.
16.6RequestForwarding
Assoonasthetargetsetisnonempty,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.UpdatetheRequestURI
3.UpdatetheMaxForwardsheaderfield
4.OptionallyaddaRecordrouteheaderfieldvalue
5.Optionallyaddadditionalheaderfields
6.Postprocessroutinginformation
7.Determinethenexthopaddress,port,andtransport
8.AddaViaheaderfieldvalue
9.AddaContentLengthheaderfieldifnecessary
10.Forwardthenewrequest
11.SettimerC
Eachofthesestepsisdetailedbelow:
1.Copyrequest
Theproxystartswithacopyofthereceivedrequest.Thecopy
MUSTinitiallycontainalloftheheaderfieldsfromthe
receivedrequest.Fieldsnotdetailedintheprocessing
describedbelowMUSTNOTberemoved.ThecopySHOULDmaintain
theorderingoftheheaderfieldsasinthereceivedrequest.
TheproxyMUSTNOTreorderfieldvalueswithacommonfield
name(SeeSection7.3.1).TheproxyMUSTNOTaddto,modify,
orremovethemessagebody.
Anactualimplementationneednotperformacopytheprimary
requirementisthattheprocessingforeachnexthopbeginwith
thesamerequest.
2.RequestURI
TheRequestURIinthecopy'sstartlineMUSTbereplacedwith
theURIforthistarget.IftheURIcontainsanyparameters
notallowedinaRequestURI,theyMUSTberemoved.
Thisistheessenceofaproxy'srole.Thisisthemechanism
throughwhichaproxyroutesarequesttowarditsdestination.
Insomecircumstances,thereceivedRequestURIisplacedinto
thetargetsetwithoutbeingmodified.Forthattarget,the
replacementaboveiseffectivelyanoop.
3.MaxForwards
IfthecopycontainsaMaxForwardsheaderfield,theproxy
MUSTdecrementitsvaluebyone(1).
IfthecopydoesnotcontainaMaxForwardsheaderfield,the
proxyMUSTaddonewithafieldvalue,whichSHOULDbe70.
SomeexistingUAswillnotprovideaMaxForwardsheaderfield
inarequest.
4.RecordRoute
Ifthisproxywishestoremainonthepathoffuturerequests
inadialogcreatedbythisrequest(assumingtherequest
createsadialog),itMUSTinsertaRecordRouteheaderfield
valueintothecopybeforeanyexistingRecordRouteheader
fieldvalues,evenifaRouteheaderfieldisalreadypresent.
RequestsestablishingadialogmaycontainapreloadedRoute
headerfield.
Ifthisrequestisalreadypartofadialog,theproxySHOULD
insertaRecordRouteheaderfieldvalueifitwishestoremain
onthepathoffuturerequestsinthedialog.Innormal
endpointoperationasdescribedinSection12,theseRecord
Routeheaderfieldvalueswillnothaveanyeffectontheroute
setsusedbytheendpoints.
Theproxywillremainonthepathifitchoosestonotinserta
RecordRouteheaderfieldvalueintorequeststhatarealready
partofadialog.However,itwouldberemovedfromthepath
whenanendpointthathasfailedreconstitutesthedialog.
AproxyMAYinsertaRecordRouteheaderfieldvalueintoany
request.Iftherequestdoesnotinitiateadialog,the
endpointswillignorethevalue.SeeSection12fordetailson
howendpointsusetheRecordRouteheaderfieldvaluesto
constructRouteheaderfields.
Eachproxyinthepathofarequestchooseswhethertoadda
RecordRouteheaderfieldvalueindependentlythepresenceof
aRecordRouteheaderfieldinarequestdoesnotobligatethis
proxytoaddavalue.
TheURIplacedintheRecordRouteheaderfieldvalueMUSTbea
SIPorSIPSURI.ThisURIMUSTcontainanlrparameter(see
Section19.1.1).ThisURIMAYbedifferentforeach
destinationtherequestisforwardedto.TheURISHOULDNOT
containthetransportparameterunlesstheproxyhasknowledge
(suchasinaprivatenetwork)thatthenextdownstreamelement
thatwillbeinthepathofsubsequentrequestssupportsthat
transport.
TheURIthisproxyprovideswillbeusedbysomeotherelement
tomakearoutingdecision.Thisproxy,ingeneral,hasnoway
ofknowingthecapabilitiesofthatelement,soitmust
restrictitselftothemandatoryelementsofaSIP
implementation:SIPURIsandeithertheTCPorUDPtransports.
TheURIplacedintheRecordRouteheaderfieldMUSTresolveto
theelementinsertingit(orasuitablestandin)whenthe
serverlocationproceduresof[4]areappliedtoit,sothat
subsequentrequestsreachthesameSIPelement.Ifthe
RequestURIcontainsaSIPSURI,orthetopmostRouteheader
fieldvalue(afterthepostprocessingofbullet6)containsa
SIPSURI,theURIplacedintotheRecordRouteheaderfield
MUSTbeaSIPSURI.Furthermore,iftherequestwasnot
receivedoverTLS,theproxyMUSTinsertaRecordRouteheader
field.Inasimilarfashion,aproxythatreceivesarequest
overTLS,butgeneratesarequestwithoutaSIPSURIinthe
RequestURIortopmostRouteheaderfieldvalue(afterthepost
processingofbullet6),MUSTinsertaRecordRouteheader
fieldthatisnotaSIPSURI.
Aproxyatasecurityperimetermustremainontheperimeter
throughoutthedialog.
IftheURIplacedintheRecordRouteheaderfieldneedstobe
rewrittenwhenitpassesbackthroughinaresponse,theURI
MUSTbedistinctenoughtolocateatthattime.(Therequest
mayspiralthroughthisproxy,resultinginmorethanone
RecordRouteheaderfieldvaluebeingadded).Item8of
Section16.7recommendsamechanismtomaketheURI
sufficientlydistinct.
TheproxyMAYincludeparametersintheRecordRouteheader
fieldvalue.Thesewillbeechoedinsomeresponsestothe
requestsuchasthe200(OK)responsestoINVITE.Such
parametersmaybeusefulforkeepingstateinthemessage
ratherthantheproxy.
Ifaproxyneedstobeinthepathofanytypeofdialog(such
asonestraddlingafirewall),itSHOULDaddaRecordRoute
headerfieldvaluetoeveryrequestwithamethoditdoesnot
understandsincethatmethodmayhavedialogsemantics.
TheURIaproxyplacesintoaRecordRouteheaderfieldisonly
validforthelifetimeofanydialogcreatedbythetransaction
inwhichitoccurs.Adialogstatefulproxy,forexample,MAY
refusetoacceptfuturerequestswiththatvalueinthe
RequestURIafterthedialoghasterminated.Nondialog
statefulproxies,ofcourse,havenoconceptofwhenthedialog
hasterminated,buttheyMAYencodeenoughinformationinthe
valuetocompareitagainstthedialogidentifieroffuture
requestsandMAYrejectrequestsnotmatchingthatinformation.
EndpointsMUSTNOTuseaURIobtainedfromaRecordRoute
headerfieldoutsidethedialoginwhichitwasprovided.See
Section12formoreinformationonanendpoint'suseof
RecordRouteheaderfields.
Recordroutingmayberequiredbycertainserviceswherethe
proxyneedstoobserveallmessagesinadialog.However,it
slowsdownprocessingandimpairsscalabilityandthusproxies
shouldonlyrecordrouteifrequiredforaparticularservice.
TheRecordRouteprocessisdesignedtoworkforanySIP
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,iftheRequestURIcontainsaSIPSURI,TLSMUST
beusedtocommunicatewiththatproxy.
IfthecopycontainsaRouteheaderfield,theproxyMUST
inspecttheURIinitsfirstvalue.IfthatURIdoesnot
containanlrparameter,theproxyMUSTmodifythecopyas
follows:
TheproxyMUSTplacetheRequestURIintotheRouteheader
fieldasthelastvalue.
TheproxyMUSTthenplacethefirstRouteheaderfieldvalue
intotheRequestURIandremovethatvaluefromtheRoute
headerfield.
AppendingtheRequestURItotheRouteheaderfieldispartof
amechanismusedtopasstheinformationinthatRequestURI
throughstrictroutingelements."Popping"thefirstRoute
headerfieldvalueintotheRequestURIformatsthemessagethe
wayastrictroutingelementexpectstoreceiveit(withits
ownURIintheRequestURIandthenextlocationtovisitin
thefirstRouteheaderfieldvalue).
7.DetermineNextHopAddress,Port,andTransport
TheproxyMAYhavealocalpolicytosendtherequesttoa
specificIPaddress,port,andtransport,independentofthe
valuesoftheRouteandRequestURI.SuchapolicyMUSTNOTbe
usediftheproxyisnotcertainthattheIPaddress,port,and
transportcorrespondtoaserverthatisalooserouter.
However,thismechanismforsendingtherequestthrougha
specificnexthopisNOTRECOMMENDEDinsteadaRouteheader
fieldshouldbeusedforthatpurposeasdescribedabove.
Intheabsenceofsuchanoverridingmechanism,theproxy
appliestheprocedureslistedin[4]asfollowstodetermine
wheretosendtherequest.Iftheproxyhasreformattedthe
requesttosendtoastrictroutingelementasdescribedin
step6above,theproxyMUSTapplythoseprocedurestothe
RequestURIoftherequest.Otherwise,theproxyMUSTapply
theprocedurestothefirstvalueintheRouteheaderfield,if
present,elsetheRequestURI.Theprocedureswillproducean
orderedsetof(address,port,transport)tuples.
IndependentlyofwhichURIisbeingusedasinputtothe
proceduresof[4],iftheRequestURIspecifiesaSIPS
resource,theproxyMUSTfollowtheproceduresof[4]asifthe
inputURIwereaSIPSURI.
Asdescribedin[4],theproxyMUSTattempttodeliverthe
messagetothefirsttupleinthatset,andproceedthroughthe
setinorderuntilthedeliveryattemptsucceeds.
Foreachtupleattempted,theproxyMUSTformatthemessageas
appropriateforthetupleandsendtherequestusinganew
clienttransactionasdetailedinsteps8through10.
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,ProxyRequireandProxy
Authorizationheaderfields).Thisistoensurethatifthe
requestisroutedbacktotheproxyandoneofthosefields
changes,itistreatedasaspiralandnotaloop(seeSection
16.3).Acommonwaytocreatethisvalueistocomputea
cryptographichashoftheTotag,Fromtag,CallIDheader
field,theRequestURIoftherequestreceived(before
translation),thetopmostViaheader,andthesequencenumber
fromtheCSeqheaderfield,inadditiontoanyProxyRequire
andProxyAuthorizationheaderfieldsthatmaybepresent.The
algorithmusedtocomputethehashisimplementationdependent,
butMD5(RFC1321[35]),expressedinhexadecimal,isa
reasonablechoice.(Base64isnotpermissibleforatoken.)
Ifaproxywishestodetectloops,the"branch"parameterit
suppliesMUSTdependonallinformationaffectingprocessingof
arequest,includingtheincomingRequestURIandanyheader
fieldsaffectingtherequest'sadmissionorrouting.Thisis
necessarytodistinguishloopedrequestsfromrequestswhose
routingparametershavechangedbeforereturningtothis
server.
TherequestmethodMUSTNOTbeincludedinthecalculationof
thebranchparameter.Inparticular,CANCELandACKrequests
(fornon2xxresponses)MUSThavethesamebranchvalueasthe
correspondingrequesttheycanceloracknowledge.Thebranch
parameterisusedincorrelatingthoserequestsattheserver
handlingthem(seeSections17.2.3and9.2).
9.AddaContentLengthheaderfieldifnecessary
Iftherequestwillbesenttothenexthopusingastream
basedtransportandthecopycontainsnoContentLengthheader
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.
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.OptionallyrewriteRecordRouteheaderfieldvalues
9.Forwardtheresponse
10.GenerateanynecessaryCANCELrequests
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,aproxySHOULDNOTrecursetoanonSIPSURI
iftheRequestURIoftheoriginalrequestwasaSIPSURI.If
theproxyrecursesonallofthecontactsina3xxresponse,
theproxySHOULDNOTaddtheresultingcontactlessresponseto
theresponsecontext.
Removingthecontactbeforeaddingtheresponsetotheresponse
contextpreventsthenextelementupstreamfromretryinga
locationthisproxyhasalreadyattempted.
3xxresponsesmaycontainamixtureofSIP,SIPS,andnonSIP
URIs.AproxymaychoosetorecurseontheSIPandSIPSURIs
andplacetheremainderintotheresponsecontexttobe
returned,potentiallyinthefinalresponse.
Ifaproxyreceivesa416(UnsupportedURIScheme)responseto
arequestwhoseRequestURIschemewasnotSIP,butthescheme
intheoriginalreceivedrequestwasSIPorSIPS(thatis,the
proxychangedtheschemefromSIPorSIPStosomethingelse
whenitproxiedarequest),theproxySHOULDaddanewURIto
thetargetset.ThisURISHOULDbeaSIPURIversionofthe
nonSIPURIthatwasjusttried.InthecaseofthetelURL,
thisisaccomplishedbyplacingthetelephonesubscriberpart
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
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"RecordRoute".
Thisstep,combinedwiththenext,ensuresthatastateful
proxywillforwardexactlyonefinalresponsetoanonINVITE
request,andeitherexactlyonenon2xxresponseoroneormore
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
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
issuenon100provisionalresponsesonitsown.However,it
canbranchtherequesttoaUASsharingthesameelementasthe
proxy.ThisUAScanreturnitsownprovisionalresponses,
enteringintoanearlydialogwiththeinitiatorofthe
request.TheUASdoesnothavetobeadiscreetprocessfrom
theproxy.ItcouldbeavirtualUASimplementedinthesame
codespaceastheproxy.
36xxresponsesaredeliveredhopbyhop.Whenissuinga36xx
response,theelementiseffectivelyactingasaUAS,issuing
itsownresponse,usuallybasedontheresponsesreceivedfrom
downstreamelements.AnelementSHOULDpreservetheTotag
whensimplyforwardinga36xxresponsetoarequestthatdid
notcontainaTotag.
AproxyMUSTNOTmodifytheTotaginanyforwardedresponseto
arequestthatcontainsaTotag.
Whileitmakesnodifferencetotheupstreamelementsifthe
proxyreplacedtheTotaginaforwarded36xxresponse,
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
AuthenticateandProxyAuthenticateheaderfieldvaluesfrom
allother401(Unauthorized)and407(ProxyAuthentication
Required)responsesreceivedsofarinthisresponsecontext
andaddthemtothisresponsewithoutmodificationbefore
forwarding.Theresulting401(Unauthorized)or407(Proxy
AuthenticationRequired)responsecouldhaveseveralWWW
AuthenticateANDProxyAuthenticateheaderfieldvalues.
Thisisnecessarybecauseanyorallofthedestinationsthe
requestwasforwardedtomayhaverequestedcredentials.The
clientneedstoreceiveallofthosechallengesandsupply
credentialsforeachofthemwhenitretriestherequest.
MotivationforthisbehaviorisprovidedinSection26.
8.RecordRoute
IftheselectedresponsecontainsaRecordRouteheaderfield
valueoriginallyprovidedbythisproxy,theproxyMAYchoose
torewritethevaluebeforeforwardingtheresponse.This
allowstheproxytoprovidedifferentURIsforitselftothe
nextupstreamanddownstreamelements.Aproxymaychooseto
usethismechanismforanyreason.Forinstance,itisuseful
formultihomedhosts.
IftheproxyreceivedtherequestoverTLS,andsentitout
overanonTLSconnection,theproxyMUSTrewritetheURIin
theRecordRouteheaderfieldtobeaSIPSURI.Iftheproxy
receivedtherequestoveranonTLSconnection,andsentitout
overTLS,theproxyMUSTrewritetheURIintheRecordRoute
headerfieldtobeaSIPURI.
ThenewURIprovidedbytheproxyMUSTsatisfythesame
constraintsonURIsplacedinRecordRouteheaderfieldsin
requests(seeStep4ofSection16.6)withthefollowing
modifications:
TheURISHOULDNOTcontainthetransportparameterunlessthe
proxyhasknowledgethatthenextupstream(asopposedto
downstream)elementthatwillbeinthepathofsubsequent
requestssupportsthattransport.
WhenaproxydoesdecidetomodifytheRecordRouteheader
fieldintheresponse,oneoftheoperationsitperformsis
locatingtheRecordRoutevaluethatithadinserted.Ifthe
requestspiraled,andtheproxyinsertedaRecordRoutevalue
ineachiterationofthespiral,locatingthecorrectvaluein
theresponse(whichmustbetheproperiterationinthereverse
direction)istricky.Therulesaboverecommendthataproxy
wishingtorewriteRecordRouteheaderfieldvaluesinsert
sufficientlydistinctURIsintotheRecordRouteheaderfield
sothattherightonemaybeselectedforrewriting.A
RECOMMENDEDmechanismtoachievethisisfortheproxyto
appendauniqueidentifierfortheproxyinstancetotheuser
portionoftheURI.
Whentheresponsearrives,theproxymodifiesthefirst
RecordRoutewhoseidentifiermatchestheproxyinstance.The
modificationresultsinaURIwithoutthispieceofdata
appendedtotheuserportionoftheURI.Uponthenext
iteration,thesamealgorithm(findthetopmostRecordRoute
headerfieldvaluewiththeparameter)willcorrectlyextract
thenextRecordRouteheaderfieldvalueinsertedbythat
proxy.
Noteveryresponsetoarequesttowhichaproxyaddsa
RecordRouteheaderfieldvaluewillcontainaRecordRoute
headerfield.IftheresponsedoescontainaRecordRoute
headerfield,itwillcontainthevaluetheproxyadded.
9.Forwardresponse
Afterperformingtheprocessingdescribedinsteps"Aggregate
AuthorizationHeaderFieldValues"through"RecordRoute",the
proxyMAYperformanyfeaturespecificmanipulationsonthe
selectedresponse.TheproxyMUSTNOTaddto,modify,or
removethemessagebody.Unlessotherwisespecified,theproxy
MUSTNOTremoveanyheaderfieldvaluesotherthantheVia
headerfieldvaluediscussedinSection16.7Item3.In
particular,theproxyMUSTNOTremoveany"received"parameter
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.
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).
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
messageandtimeinvariantpropertiesoftheserver.In
particular,aretransmittedrequestMUSTbeforwardedtothe
samedestinationeachtimeitisprocessed.Furthermore,
CANCELandnonRoutedACKrequestsMUSTgeneratethesame
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.
ThestatelessproxyMAYuseanytechniqueitlikestoguarantee
uniquenessofitsbranchIDsacrosstransactions.However,the
followingprocedureisRECOMMENDED.Theproxyexaminesthe
branchIDinthetopmostViaheaderfieldofthereceived
request.Ifitbeginswiththemagiccookie,thefirst
componentofthebranchIDoftheoutgoingrequestiscomputed
asahashofthereceivedbranchID.Otherwise,thefirst
componentofthebranchIDiscomputedasahashofthetopmost
Via,thetagintheToheaderfield,thetagintheFromheader
field,theCallIDheaderfield,theCSeqnumber(butnot
method),andtheRequestURIfromthereceivedrequest.Oneof
thesefieldswillalwaysvaryacrosstwodifferent
transactions.
oAllothermessagetransformationsspecifiedinSection16.6
MUSTresultinthesametransformationofaretransmitted
request.Inparticular,iftheproxyinsertsaRecordRoute
valueorpushesURIsintotheRouteheaderfield,itMUSTplace
thesamevaluesinretransmissionsoftherequest.Asforthe
Viabranchparameter,thisimpliesthatthetransformations
MUSTbebasedontimeinvariantconfigurationor
retransmissioninvariantpropertiesoftherequest.
oAstatelessproxydetermineswheretoforwardtherequestas
describedforstatefulproxiesinSection16.6Item10.The
requestissentdirectlytothetransportlayerinsteadof
throughaclienttransaction.
Sinceastatelessproxymustforwardretransmittedrequeststo
thesamedestinationandaddidenticalbranchparametersto
eachofthem,itcanonlyuseinformationfromthemessage
itselfandtimeinvariantconfigurationdataforthose
calculations.Iftheconfigurationstateisnottimeinvariant
(forexample,ifaroutingtableisupdated)anyrequeststhat
couldbeaffectedbythechangemaynotbeforwarded
statelesslyduringanintervalequaltothetransactiontimeout
windowbeforeorafterthechange.Themethodofprocessing
theaffectedrequestsinthatintervalisanimplementation
decision.Acommonsolutionistoforwardthemtransaction
statefully.
StatelessproxiesMUSTNOTperformspecialprocessingforCANCEL
requests.Theyareprocessedbytheaboverulesasanyother
requests.Inparticular,astatelessproxyappliesthesameRoute
headerfieldprocessingtoCANCELrequeststhatitappliestoany
otherrequest.
ResponseprocessingasdescribedinSection16.7doesnotapplytoa
proxybehavingstatelessly.Whenaresponsearrivesatastateless
proxy,theproxyMUSTinspectthesentbyvalueinthefirst
(topmost)Viaheaderfieldvalue.Ifthataddressmatchestheproxy,
(itequalsavaluethisproxyhasinsertedintopreviousrequests)
theproxyMUSTremovethatheaderfieldvaluefromtheresponseand
forwardtheresulttothelocationindicatedinthenextViaheader
fieldvalue.TheproxyMUSTNOTaddto,modify,orremovethe
messagebody.Unlessspecifiedotherwise,theproxyMUSTNOTremove
anyotherheaderfieldvalues.Iftheaddressdoesnotmatchthe
proxy,themessageMUSTbesilentlydiscarded.
16.12SummaryofProxyRouteProcessing
Intheabsenceoflocalpolicytothecontrary,theprocessinga
proxyperformsonarequestcontainingaRouteheaderfieldcanbe
summarizedinthefollowingsteps.
1.TheproxywillinspecttheRequestURI.Ifitindicatesa
resourceownedbythisproxy,theproxywillreplaceitwith
theresultsofrunningalocationservice.Otherwise,the
proxywillnotchangetheRequestURI.
2.TheproxywillinspecttheURIinthetopmostRouteheader
fieldvalue.Ifitindicatesthisproxy,theproxyremovesit
fromtheRouteheaderfield(thisroutenodehasbeen
reached).
3.Theproxywillforwardtherequesttotheresourceindicated
bytheURIinthetopmostRouteheaderfieldvalueorinthe
RequestURIifnoRouteheaderfieldispresent.Theproxy
determinestheaddress,portandtransporttousewhen
forwardingtherequestbyapplyingtheproceduresin[4]to
thatURI.
Ifnostrictroutingelementsareencounteredonthepathofthe
request,theRequestURIwillalwaysindicatethetargetofthe
request.
16.12.1Examples
16.12.1.1BasicSIPTrapezoid
ThisscenarioisthebasicSIPtrapezoid,U1>P1>P2>U2,with
bothproxiesrecordrouting.Hereistheflow.
U1sends:
INVITEsip:callee@domain.comSIP/2.0
Contact:sip:caller@u1.example.com
toP1.P1isanoutboundproxy.P1isnotresponsiblefor
domain.com,soitlooksitupinDNSandsendsitthere.Italso
addsaRecordRouteheaderfieldvalue:
INVITEsip:callee@domain.comSIP/2.0
RecordRoute:<sip:p1.example.comlr>
P2getsthis.Itisresponsiblefordomain.comsoitrunsalocation
serviceandrewritestheRequestURI.ItalsoaddsaRecordRoute
headerfieldvalue.ThereisnoRouteheaderfield,soitresolves
thenewRequestURItodeterminewheretosendtherequest:
INVITEsip:callee@u2.domain.comSIP/2.0
RecordRoute:<sip:p2.domain.comlr>
Thecalleeatu2.domain.comgetsthisandrespondswitha200OK:
SIP/2.0200OK
Contact:sip:callee@u2.domain.com
Thecalleeatu2alsosetsitsdialogstate'sremotetargetURIto
sip:caller@u1.example.comanditsroutesetto:
(<sip:p2.domain.comlr>,<sip:p1.example.comlr>)
ThisisforwardedbyP2toP1toU1asnormal.Now,U1setsits
dialogstate'sremotetargetURItosip:callee@u2.domain.comandits
routesetto:
(<sip:p1.example.comlr>,<sip:p2.domain.comlr>)
Sincealltheroutesetelementscontainthelrparameter,U1
constructsthefollowingBYErequest:
BYEsip:callee@u2.domain.comSIP/2.0
Route:<sip:p1.example.comlr>,<sip:p2.domain.comlr>
Asanyotherelement(includingproxies)woulddo,itresolvesthe
URIinthetopmostRouteheaderfieldvalueusingDNStodetermine
wheretosendtherequest.ThisgoestoP1.P1noticesthatitis
notresponsiblefortheresourceindicatedintheRequestURIsoit
doesn'tchangeit.Itdoesseethatitisthefirstvalueinthe
Routeheaderfield,soitremovesthatvalue,andforwardsthe
requesttoP2:
Route:<sip:p2.domain.comlr>
P2alsonoticesitisnotresponsiblefortheresourceindicatedby
theRequestURI(itisresponsiblefordomain.com,not
u2.domain.com),soitdoesn'tchangeit.Itdoesseeitselfinthe
firstRouteheaderfieldvalue,soitremovesitandforwardsthe
followingtou2.domain.combasedonaDNSlookupagainstthe
RequestURI:
16.12.1.2TraversingaStrictRoutingProxy
Inthisscenario,adialogisestablishedacrossfourproxies,each
ofwhichaddsRecordRouteheaderfieldvalues.Thethirdproxy
implementsthestrictroutingproceduresspecifiedinRFC2543and
manyworksinprogress.
U1>P1>P2>P3>P4>U2
TheINVITEarrivingatU2contains:
INVITEsip:callee@u2.domain.comSIP/2.0
RecordRoute:<sip:p3.middle.com>
WhichU2respondstowitha200OK.Later,U2sendsthefollowing
BYErequesttoP4basedonthefirstRouteheaderfieldvalue.
BYEsip:caller@u1.example.comSIP/2.0
Route:<sip:p4.domain.comlr>
Route:<sip:p3.middle.com>
Route:<sip:p2.example.comlr>
P4isnotresponsiblefortheresourceindicatedintheRequestURI
soitwillleaveitalone.Itnoticesthatitistheelementinthe
firstRouteheaderfieldvaluesoitremovesit.Itthenpreparesto
sendtherequestbasedonthenowfirstRouteheaderfieldvalueof
sip:p3.middle.com,butitnoticesthatthisURIdoesnotcontainthe
lrparameter,sobeforesending,itreformatstherequesttobe:
BYEsip:p3.middle.comSIP/2.0
Route:<sip:caller@u1.example.com>
P3isastrictrouter,soitforwardsthefollowingtoP2:
BYEsip:p2.example.comlrSIP/2.0
Route:<sip:caller@u1.example.com>
P2seestherequestURIisavalueitplacedintoaRecordRoute
headerfield,sobeforefurtherprocessing,itrewritestherequest
tobe:
P2isnotresponsibleforu1.example.com,soitsendstherequestto
P1basedontheresolutionoftheRouteheaderfieldvalue.
P1noticesitselfinthetopmostRouteheaderfieldvalue,soit
removesit,resultingin:
SinceP1isnotresponsibleforu1.example.comandthereisnoRoute
headerfield,P1willforwardtherequesttou1.example.combasedon
theRequestURI.
16.12.1.3RewritingRecordRouteHeaderFieldValues
Inthisscenario,U1andU2areindifferentprivatenamespacesand
theyenteradialogthroughaproxyP1,whichactsasagateway
betweenthenamespaces.
U1>P1>U2
U1sends:
INVITEsip:callee@gateway.leftprivatespace.comSIP/2.0
Contact:<sip:caller@u1.leftprivatespace.com>
P1usesitslocationserviceandsendsthefollowingtoU2:
INVITEsip:callee@rightprivatespace.comSIP/2.0
Contact:<sip:caller@u1.leftprivatespace.com>
RecordRoute:<sip:gateway.rightprivatespace.comlr>
U2sendsthis200(OK)backtoP1:
SIP/2.0200OK
Contact:<sip:callee@u2.rightprivatespace.com>
RecordRoute:<sip:gateway.rightprivatespace.comlr>
P1rewritesitsRecordRouteheaderparametertoprovideavaluethat
U1willfinduseful,andsendsthefollowingtoU1:
SIP/2.0200OK
Contact:<sip:callee@u2.rightprivatespace.com>
RecordRoute:<sip:gateway.leftprivatespace.comlr>
Later,U1sendsthefollowingBYErequesttoP1:
BYEsip:callee@u2.rightprivatespace.comSIP/2.0
Route:<sip:gateway.leftprivatespace.comlr>
whichP1forwardstoU2as:
BYEsip:callee@u2.rightprivatespace.comSIP/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
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||
|++|<|++++|<|++++|<|++|
++++++++
UACOutboundInboundUAS
ProxyProxy
Figure4:Transactionrelationships
Astatelessproxydoesnotcontainaclientorservertransaction.
ThetransactionexistsbetweentheUAorstatefulproxyononeside,
andtheUAorstatefulproxyontheotherside.AsfarasSIP
transactionsareconcerned,statelessproxiesareeffectively
transparent.Thepurposeoftheclienttransactionistoreceivea
requestfromtheelementinwhichtheclientisembedded(callthis
elementthe"TransactionUser"orTUitcanbeaUAorastateful
proxy),andreliablydelivertherequesttoaservertransaction.
Theclienttransactionisalsoresponsibleforreceivingresponses
anddeliveringthemtotheTU,filteringoutanyresponse
retransmissionsordisallowedresponses(suchasaresponsetoACK).
Additionally,inthecaseofanINVITErequest,theclient
transactionisresponsibleforgeneratingtheACKrequestforany
finalresponseacceptinga2xxresponse.
Similarly,thepurposeoftheservertransactionistoreceive
requestsfromthetransportlayeranddeliverthemtotheTU.The
servertransactionfiltersanyrequestretransmissionsfromthe
network.TheservertransactionacceptsresponsesfromtheTUand
deliversthemtothetransportlayerfortransmissionoverthe
network.InthecaseofanINVITEtransaction,itabsorbstheACK
requestforanyfinalresponseexceptinga2xxresponse.
The2xxresponseanditsACKreceivespecialtreatment.This
responseisretransmittedonlybyaUAS,anditsACKgeneratedonly
bytheUAC.Thisendtoendtreatmentisneededsothatacaller
knowstheentiresetofusersthathaveacceptedthecall.Because
ofthisspecialhandling,retransmissionsofthe2xxresponseare
handledbytheUAcore,notthetransactionlayer.Similarly,
generationoftheACKforthe2xxishandledbytheUAcore.Each
proxyalongthepathmerelyforwardseach2xxresponsetoINVITEand
itscorrespondingACK.
17.1ClientTransaction
Theclienttransactionprovidesitsfunctionalitythroughthe
maintenanceofastatemachine.
TheTUcommunicateswiththeclienttransactionthroughasimple
interface.WhentheTUwishestoinitiateanewtransaction,it
createsaclienttransactionandpassesittheSIPrequesttosend
andanIPaddress,port,andtransporttowhichtosendit.The
clienttransactionbeginsexecutionofitsstatemachine.Valid
responsesarepasseduptotheTUfromtheclienttransaction.
Therearetwotypesofclienttransactionstatemachines,depending
onthemethodoftherequestpassedbytheTU.Onehandlesclient
transactionsforINVITErequests.Thistypeofmachineisreferred
toasanINVITEclienttransaction.Anothertypehandlesclient
transactionsforallrequestsexceptINVITEandACK.Thisis
referredtoasanonINVITEclienttransaction.Thereisnoclient
transactionforACK.IftheTUwishestosendanACK,itpassesone
directlytothetransportlayerfortransmission.
TheINVITEtransactionisdifferentfromthoseofothermethods
becauseofitsextendedduration.Normally,humaninputisrequired
inordertorespondtoanINVITE.Thelongdelaysexpectedfor
sendingaresponseargueforathreewayhandshake.Ontheother
hand,requestsofothermethodsareexpectedtocompleterapidly.
BecauseofthenonINVITEtransaction'srelianceonatwoway
handshake,TUsSHOULDrespondimmediatelytononINVITErequests.
17.1.1INVITEClientTransaction
17.1.1.1OverviewofINVITETransaction
TheINVITEtransactionconsistsofathreewayhandshake.Theclient
transactionsendsanINVITE,theservertransactionsendsresponses,
andtheclienttransactionsendsanACK.Forunreliabletransports
(suchasUDP),theclienttransactionretransmitsrequestsatan
intervalthatstartsatT1secondsanddoublesafterevery
retransmission.T1isanestimateoftheroundtriptime(RTT),and
itdefaultsto500ms.Nearlyallofthetransactiontimers
describedherescalewithT1,andchangingT1adjuststheirvalues.
Therequestisnotretransmittedoverreliabletransports.After
receivinga1xxresponse,anyretransmissionsceasealtogether,and
theclientwaitsforfurtherresponses.Theservertransactioncan
sendadditional1xxresponses,whicharenottransmittedreliablyby
theservertransaction.Eventually,theservertransactiondecides
tosendafinalresponse.Forunreliabletransports,thatresponse
isretransmittedperiodically,andforreliabletransports,itis
sentonce.Foreachfinalresponsethatisreceivedattheclient
transaction,theclienttransactionsendsanACK,thepurposeof
whichistoquenchretransmissionsoftheresponse.
17.1.1.2FormalDescription
ThestatemachinefortheINVITEclienttransactionisshownin
Figure5.Theinitialstate,"calling",MUSTbeenteredwhentheTU
initiatesanewclienttransactionwithanINVITErequest.The
clienttransactionMUSTpasstherequesttothetransportlayerfor
transmission(seeSection18).Ifanunreliabletransportisbeing
used,theclienttransactionMUSTstarttimerAwithavalueofT1.
Ifareliabletransportisbeingused,theclienttransactionSHOULD
NOTstarttimerA(TimerAcontrolsrequestretransmissions).For
anytransport,theclienttransactionMUSTstarttimerBwithavalue
of64*T1seconds(TimerBcontrolstransactiontimeouts).
WhentimerAfires,theclienttransactionMUSTretransmitthe
requestbypassingittothetransportlayer,andMUSTresetthe
timerwithavalueof2*T1.Theformaldefinitionofretransmit
withinthecontextofthetransactionlayeristotakethemessage
previouslysenttothetransportlayerandpassittothetransport
layeroncemore.
WhentimerAfires2*T1secondslater,therequestMUSTbe
retransmittedagain(assumingtheclienttransactionisstillinthis
state).ThisprocessMUSTcontinuesothattherequestis
retransmittedwithintervalsthatdoubleaftereachtransmission.
TheseretransmissionsSHOULDonlybedonewhiletheclient
transactionisinthe"calling"state.
ThedefaultvalueforT1is500ms.T1isanestimateoftheRTT
betweentheclientandservertransactions.ElementsMAY(thoughit
isNOTRECOMMENDED)usesmallervaluesofT1withinclosed,private
networksthatdonotpermitgeneralInternetconnection.T1MAYbe
chosenlarger,andthisisRECOMMENDEDifitisknowninadvance
(suchasonhighlatencyaccesslinks)thattheRTTislarger.
WhateverthevalueofT1,theexponentialbackoffsonretransmissions
describedinthissectionMUSTbeused.
Iftheclienttransactionisstillinthe"Calling"statewhentimer
Bfires,theclienttransactionSHOULDinformtheTUthatatimeout
hasoccurred.TheclienttransactionMUSTNOTgenerateanACK.The
valueof64*T1isequaltotheamountoftimerequiredtosendseven
requestsinthecaseofanunreliabletransport.
Iftheclienttransactionreceivesaprovisionalresponsewhilein
the"Calling"state,ittransitionstothe"Proceeding"state.Inthe
"Proceeding"state,theclienttransactionSHOULDNOTretransmitthe
requestanylonger.Furthermore,theprovisionalresponseMUSTbe
passedtotheTU.AnyfurtherprovisionalresponsesMUSTbepassed
uptotheTUwhileinthe"Proceeding"state.
Whenineitherthe"Calling"or"Proceeding"states,receptionofa
responsewithstatuscodefrom300699MUSTcausetheclient
transactiontotransitionto"Completed".Theclienttransaction
MUSTpassthereceivedresponseuptotheTU,andtheclient
transactionMUSTgenerateanACKrequest,evenifthetransportis
reliable(guidelinesforconstructingtheACKfromtheresponseare
giveninSection17.1.1.3)andthenpasstheACKtothetransport
layerfortransmission.TheACKMUSTbesenttothesameaddress,
port,andtransporttowhichtheoriginalrequestwassent.The
clienttransactionSHOULDstarttimerDwhenitentersthe
"Completed"state,withavalueofatleast32secondsforunreliable
transports,andavalueofzerosecondsforreliabletransports.
TimerDreflectstheamountoftimethattheservertransactioncan
remaininthe"Completed"statewhenunreliabletransportsareused.
ThisisequaltoTimerHintheINVITEservertransaction,whose
defaultis64*T1.However,theclienttransactiondoesnotknowthe
valueofT1inusebytheservertransaction,soanabsoluteminimum
of32sisusedinsteadofbasingTimerDonT1.
Anyretransmissionsofthefinalresponsethatarereceivedwhilein
the"Completed"stateMUSTcausetheACKtoberepassedtothe
transportlayerforretransmission,butthenewlyreceivedresponse
MUSTNOTbepasseduptotheTU.Aretransmissionoftheresponseis
definedasanyresponsewhichwouldmatchthesameclienttransaction
basedontherulesofSection17.1.3.
|INVITEfromTU
TimerAfires|INVITEsent
ResetA,VTimerBfires
INVITEsent++orTransportErr.
+||+informTU
||Calling||
+>||>|
++2xx|
||2xxtoTU|
||1xx|
300699++|1xxtoTU|
ACKsent|||
resp.toTU|1xxV|
|1xxtoTU+|
|+|||
|||Proceeding|>|
|+>||2xx|
|++2xxtoTU|
|300699||
|ACKsent,||
|resp.toTU||
|||NOTE:
|300699V|
|ACKsent++TransportErr.|transitions
|+||InformTU|labeledwith
|||Completed|>|theevent
|+>|||overtheaction
|++|totake
|^||
|||TimerDfires|
++||
||
V|
++|
|||
|Terminated|<+
||
++
Figure5:INVITEclienttransaction
IftimerDfireswhiletheclienttransactionisinthe"Completed"
state,theclienttransactionMUSTmovetotheterminatedstate.
Whenineitherthe"Calling"or"Proceeding"states,receptionofa
2xxresponseMUSTcausetheclienttransactiontoenterthe
"Terminated"state,andtheresponseMUSTbepasseduptotheTU.
ThehandlingofthisresponsedependsonwhethertheTUisaproxy
coreoraUACcore.AUACcorewillhandlegenerationoftheACKfor
thisresponse,whileaproxycorewillalwaysforwardthe200(OK)
upstream.Thedifferingtreatmentof200(OK)betweenproxyandUAC
isthereasonthathandlingofitdoesnottakeplaceinthe
transactionlayer.
TheclienttransactionMUSTbedestroyedtheinstantitentersthe
"Terminated"state.Thisisactuallynecessarytoguaranteecorrect
operation.Thereasonisthat2xxresponsestoanINVITEaretreated
differentlyeachoneisforwardedbyproxies,andtheACKhandling
inaUACisdifferent.Thus,each2xxneedstobepassedtoaproxy
core(sothatitcanbeforwarded)andtoaUACcore(soitcanbe
acknowledged).Notransactionlayerprocessingtakesplace.
Wheneveraresponseisreceivedbythetransport,ifthetransport
layerfindsnomatchingclienttransaction(usingtherulesof
Section17.1.3),theresponseispasseddirectlytothecore.Since
thematchingclienttransactionisdestroyedbythefirst2xx,
subsequent2xxwillfindnomatchandthereforebepassedtothe
core.
17.1.1.3ConstructionoftheACKRequest
ThissectionspecifiestheconstructionofACKrequestssentwithin
theclienttransaction.AUACcorethatgeneratesanACKfor2xx
MUSTinsteadfollowtherulesdescribedinSection13.
TheACKrequestconstructedbytheclienttransactionMUSTcontain
valuesfortheCallID,From,andRequestURIthatareequaltothe
valuesofthoseheaderfieldsintherequestpassedtothetransport
bytheclienttransaction(callthisthe"originalrequest").TheTo
headerfieldintheACKMUSTequaltheToheaderfieldinthe
responsebeingacknowledged,andthereforewillusuallydifferfrom
theToheaderfieldintheoriginalrequestbytheadditionofthe
tagparameter.TheACKMUSTcontainasingleViaheaderfield,and
thisMUSTbeequaltothetopViaheaderfieldoftheoriginal
request.TheCSeqheaderfieldintheACKMUSTcontainthesame
valueforthesequencenumberaswaspresentintheoriginalrequest,
butthemethodparameterMUSTbeequalto"ACK".
IftheINVITErequestwhoseresponseisbeingacknowledgedhadRoute
headerfields,thoseheaderfieldsMUSTappearintheACK.Thisis
toensurethattheACKcanberoutedproperlythroughanydownstream
statelessproxies.
AlthoughanyrequestMAYcontainabody,abodyinanACKisspecial
sincetherequestcannotberejectedifthebodyisnotunderstood.
Therefore,placementofbodiesinACKfornon2xxisNOTRECOMMENDED,
butifdone,thebodytypesarerestrictedtoanythatappearedin
theINVITE,assumingthattheresponsetotheINVITEwasnot415.If
itwas,thebodyintheACKMAYbeanytypelistedintheAccept
headerfieldinthe415.
Forexample,considerthefollowingrequest:
Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bKkjshdyff
From:Alice<sip:alice@atlanta.com>tag=88sja8x
MaxForwards:70
CallID:987asjd97y7atg
CSeq:986759INVITE
TheACKrequestforanon2xxfinalresponsetothisrequestwould
looklikethis:
ACKsip:bob@biloxi.comSIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bKkjshdyff
To:Bob<sip:bob@biloxi.com>tag=99sa0xk
From:Alice<sip:alice@atlanta.com>tag=88sja8x
MaxForwards:70
CallID:987asjd97y7atg
CSeq:986759ACK
17.1.2NonINVITEClientTransaction
17.1.2.1OverviewofthenonINVITETransaction
NonINVITEtransactionsdonotmakeuseofACK.Theyaresimple
requestresponseinteractions.Forunreliabletransports,requests
areretransmittedatanintervalwhichstartsatT1anddoublesuntil
ithitsT2.Ifaprovisionalresponseisreceived,retransmissions
continueforunreliabletransports,butatanintervalofT2.The
servertransactionretransmitsthelastresponseitsent,whichcan
beaprovisionalorfinalresponse,onlywhenaretransmissionofthe
requestisreceived.Thisiswhyrequestretransmissionsneedto
continueevenafteraprovisionalresponsetheyaretoensure
reliabledeliveryofthefinalresponse.
UnlikeanINVITEtransaction,anonINVITEtransactionhasnospecial
handlingforthe2xxresponse.Theresultisthatonlyasingle2xx
responsetoanonINVITEiseverdeliveredtoaUAC.
17.1.2.2FormalDescription
ThestatemachineforthenonINVITEclienttransactionisshownin
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,
anditrepresentstheamountoftimeanonINVITEservertransaction
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
codes200699)isreceivedwhileinthe"Trying"state,theresponse
MUSTbepassedtotheTU,andtheclienttransactionMUSTtransition
tothe"Completed"state.
IfTimerEfireswhileinthe"Proceeding"state,therequestMUSTbe
passedtothetransportlayerforretransmission,andTimerEMUSTbe
resetwithavalueofT2seconds.IftimerFfireswhileinthe
"Proceeding"state,theTUMUSTbeinformedofatimeout,andthe
clienttransactionMUSTtransitiontotheterminatedstate.Ifa
finalresponse(statuscodes200699)isreceivedwhileinthe
"Proceeding"state,theresponseMUSTbepassedtotheTU,andthe
clienttransactionMUSTtransitiontothe"Completed"state.
Oncetheclienttransactionentersthe"Completed"state,itMUSTset
TimerKtofireinT4secondsforunreliabletransports,andzero
secondsforreliabletransports.The"Completed"stateexiststo
bufferanyadditionalresponseretransmissionsthatmaybereceived
(whichiswhytheclienttransactionremainsthereonlyfor
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.
ThatisnotanerrormulticastSIPprovidesonlyarudimentary
"singlehopdiscoverylike"servicethatislimitedtoprocessinga
singleresponse.SeeSection18.1.1fordetails.
17.1.4HandlingTransportErrors
|RequestfromTU
|sendrequest
TimerEV
sendrequest++
+||+
||Trying|TimerF|
+>||orTransportErr.|
++informTU|
200699|||
resp.toTU||1xx|
++|resp.toTU|
|||
|TimerEVTimerF|
|sendreq++orTransportErr.|
|+||informTU|
|||Proceeding|>|
|+>||+|
|++|1xx|
||^|resptoTU|
|200699|++|
|resp.toTU||
|||
|V|
|++|
||||
||Completed||
||||
|++|
|^||
|||TimerK|
++||
||
V|
NOTE:++|
|||
transitions|Terminated|<+
labeledwith||
theevent++
overtheaction
totake
Figure6:nonINVITEclienttransaction
Whentheclienttransactionsendsarequesttothetransportlayerto
besent,thefollowingproceduresarefollowedifthetransportlayer
indicatesafailure.
TheclienttransactionSHOULDinformtheTUthatatransportfailure
hasoccurred,andtheclienttransactionSHOULDtransitiondirectly
tothe"Terminated"state.TheTUwillhandlethefailover
mechanismsdescribedin[4].
17.2ServerTransaction
Theservertransactionisresponsibleforthedeliveryofrequeststo
theTUandthereliabletransmissionofresponses.Itaccomplishes
thisthroughastatemachine.Servertransactionsarecreatedbythe
corewhenarequestisreceived,andtransactionhandlingisdesired
forthatrequest(thisisnotalwaysthecase).
Aswiththeclienttransactions,thestatemachinedependsonwhether
thereceivedrequestisanINVITErequest.
17.2.1INVITEServerTransaction
ThestatediagramfortheINVITEservertransactionisshownin
Figure7.
Whenaservertransactionisconstructedforarequest,itentersthe
"Proceeding"state.TheservertransactionMUSTgeneratea100
(Trying)responseunlessitknowsthattheTUwillgeneratea
provisionalorfinalresponsewithin200ms,inwhichcaseitMAY
generatea100(Trying)response.Thisprovisionalresponseis
neededtoquenchrequestretransmissionsrapidlyinordertoavoid
networkcongestion.The100(Trying)responseisconstructed
accordingtotheproceduresinSection8.2.6,exceptthatthe
insertionoftagsintheToheaderfieldoftheresponse(whennone
waspresentintherequest)isdowngradedfromMAYtoSHOULDNOT.
TherequestMUSTbepassedtotheTU.
TheTUpassesanynumberofprovisionalresponsestotheserver
transaction.Solongastheservertransactionisinthe
"Proceeding"state,eachoftheseMUSTbepassedtothetransport
layerfortransmission.Theyarenotsentreliablybythe
transactionlayer(theyarenotretransmittedbyit)anddonotcause
achangeinthestateoftheservertransaction.Ifarequest
retransmissionisreceivedwhileinthe"Proceeding"state,themost
recentprovisionalresponsethatwasreceivedfromtheTUMUSTbe
passedtothetransportlayerforretransmission.Arequestisa
retransmissionifitmatchesthesameservertransactionbasedonthe
rulesofSection17.2.3.
If,whileinthe"Proceeding"state,theTUpassesa2xxresponseto
theservertransaction,theservertransactionMUSTpassthis
responsetothetransportlayerfortransmission.Itisnot
retransmittedbytheservertransactionretransmissionsof2xx
responsesarehandledbytheTU.TheservertransactionMUSTthen
transitiontothe"Terminated"state.
Whileinthe"Proceeding"state,iftheTUpassesaresponsewith
statuscodefrom300to699totheservertransaction,theresponse
MUSTbepassedtothetransportlayerfortransmission,andthestate
machineMUSTenterthe"Completed"state.Forunreliabletransports,
timerGissettofireinT1seconds,andisnotsettofirefor
reliabletransports.
ThisisachangefromRFC2543,whereresponseswerealways
retransmitted,evenoverreliabletransports.
Whenthe"Completed"stateisentered,timerHMUSTbesettofirein
64*T1secondsforalltransports.TimerHdetermineswhentheserver
transactionabandonsretransmittingtheresponse.Itsvalueis
chosentoequalTimerB,theamountoftimeaclienttransactionwill
continuetoretrysendingarequest.IftimerGfires,theresponse
ispassedtothetransportlayeroncemoreforretransmission,and
timerGissettofireinMIN(2*T1,T2)seconds.Fromthenon,when
timerGfires,theresponseispassedtothetransportagainfor
transmission,andtimerGisresetwithavaluethatdoubles,unless
thatvalueexceedsT2,inwhichcaseitisresetwiththevalueof
T2.Thisisidenticaltotheretransmitbehaviorforrequestsinthe
"Trying"stateofthenonINVITEclienttransaction.Furthermore,
whileinthe"Completed"state,ifarequestretransmissionis
received,theserverSHOULDpasstheresponsetothetransportfor
retransmission.
IfanACKisreceivedwhiletheservertransactionisinthe
"Completed"state,theservertransactionMUSTtransitiontothe
"Confirmed"state.AsTimerGisignoredinthisstate,any
retransmissionsoftheresponsewillcease.
IftimerHfireswhileinthe"Completed"state,itimpliesthatthe
ACKwasneverreceived.Inthiscase,theservertransactionMUST
transitiontothe"Terminated"state,andMUSTindicatetotheTU
thatatransactionfailurehasoccurred.
|INVITE
|passINVtoTU
INVITEVsend100ifTUwon'tin200ms
sendresponse++
+||+101199fromTU
||Proceeding||sendresponse
+>||<+
||TransportErr.
||InformTU
||>+
++|
300699fromTU||2xxfromTU|
sendresponse||sendresponse|
|+>+
||
INVITEVTimerGfires|
sendresponse++sendresponse|
+||+|
||Completed|||
+>||<+|
++|
|||
ACK|||
|+>+
|TimerHfires|
VorTransportErr.|
++InformTU|
|||
|Confirmed||
|||
++|
||
|TimerIfires|
||
||
V|
++|
|||
|Terminated|<+
||
++
Figure7:INVITEservertransaction
Thepurposeofthe"Confirmed"stateistoabsorbanyadditionalACK
messagesthatarrive,triggeredfromretransmissionsofthefinal
response.Whenthisstateisentered,timerIissettofireinT4
secondsforunreliabletransports,andzerosecondsforreliable
transports.OncetimerIfires,theserverMUSTtransitiontothe
"Terminated"state.
Oncethetransactionisinthe"Terminated"state,itMUSTbe
destroyedimmediately.Aswithclienttransactions,thisisneeded
toensurereliabilityofthe2xxresponsestoINVITE.
17.2.2NonINVITEServerTransaction
ThestatemachineforthenonINVITEservertransactionisshownin
Figure8.
Thestatemachineisinitializedinthe"Trying"stateandispassed
arequestotherthanINVITEorACKwheninitialized.Thisrequestis
passeduptotheTU.Onceinthe"Trying"state,anyfurtherrequest
retransmissionsarediscarded.Arequestisaretransmissionifit
matchesthesameservertransaction,usingtherulesspecifiedin
Section17.2.3.
Whileinthe"Trying"state,iftheTUpassesaprovisionalresponse
totheservertransaction,theservertransactionMUSTenterthe
"Proceeding"state.TheresponseMUSTbepassedtothetransport
layerfortransmission.Anyfurtherprovisionalresponsesthatare
receivedfromtheTUwhileinthe"Proceeding"stateMUSTbepassed
tothetransportlayerfortransmission.Ifaretransmissionofthe
requestisreceivedwhileinthe"Proceeding"state,themost
recentlysentprovisionalresponseMUSTbepassedtothetransport
layerforretransmission.IftheTUpassesafinalresponse(status
codes200699)totheserverwhileinthe"Proceeding"state,the
transactionMUSTenterthe"Completed"state,andtheresponseMUST
bepassedtothetransportlayerfortransmission.
Whentheservertransactionentersthe"Completed"state,itMUSTset
TimerJtofirein64*T1secondsforunreliabletransports,andzero
secondsforreliabletransports.Whileinthe"Completed"state,the
servertransactionMUSTpassthefinalresponsetothetransport
layerforretransmissionwheneveraretransmissionoftherequestis
received.AnyotherfinalresponsespassedbytheTUtotheserver
transactionMUSTbediscardedwhileinthe"Completed"state.The
servertransactionremainsinthisstateuntilTimerJfires,at
whichpointitMUSTtransitiontothe"Terminated"state.
TheservertransactionMUSTbedestroyedtheinstantitentersthe
"Terminated"state.
17.2.3MatchingRequeststoServerTransactions
Whenarequestisreceivedfromthenetworkbytheserver,ithasto
bematchedtoanexistingtransaction.Thisisaccomplishedinthe
followingmanner.
ThebranchparameterinthetopmostViaheaderfieldoftherequest
isexamined.Ifitispresentandbeginswiththemagiccookie
"z9hG4bK",therequestwasgeneratedbyaclienttransaction
complianttothisspecification.Therefore,thebranchparameter
willbeuniqueacrossalltransactionssentbythatclient.The
requestmatchesatransactionif:
1.thebranchparameterintherequestisequaltotheoneinthe
topViaheaderfieldoftherequestthatcreatedthe
transaction,and
2.thesentbyvalueinthetopViaoftherequestisequaltothe
oneintherequestthatcreatedthetransaction,and
3.themethodoftherequestmatchestheonethatcreatedthe
transaction,exceptforACK,wherethemethodoftherequest
thatcreatedthetransactionisINVITE.
ThismatchingruleappliestobothINVITEandnonINVITEtransactions
alike.
Thesentbyvalueisusedaspartofthematchingprocessbecause
therecouldbeaccidentalormaliciousduplicationofbranch
parametersfromdifferentclients.
IfthebranchparameterinthetopViaheaderfieldisnotpresent,
ordoesnotcontainthemagiccookie,thefollowingproceduresare
used.TheseexisttohandlebackwardscompatibilitywithRFC2543
compliantimplementations.
TheINVITErequestmatchesatransactioniftheRequestURI,Totag,
Fromtag,CallID,CSeq,andtopViaheaderfieldmatchthoseofthe
INVITErequestwhichcreatedthetransaction.Inthiscase,the
INVITEisaretransmissionoftheoriginalonethatcreatedthe
transaction.TheACKrequestmatchesatransactioniftheRequest
URI,Fromtag,CallID,CSeqnumber(notthemethod),andtopVia
headerfieldmatchthoseoftheINVITErequestwhichcreatedthe
transaction,andtheTotagoftheACKmatchestheTotagofthe
responsesentbytheservertransaction.Matchingisdonebasedon
thematchingrulesdefinedforeachofthoseheaderfields.
InclusionofthetagintheToheaderfieldintheACKmatching
processhelpsdisambiguateACKfor2xxfromACKforotherresponses
ataproxy,whichmayhaveforwardedbothresponses(Thiscanoccur
inunusualconditions.Specifically,whenaproxyforkedarequest,
andthencrashes,theresponsesmaybedeliveredtoanotherproxy,
whichmightendupforwardingmultipleresponsesupstream).AnACK
requestthatmatchesanINVITEtransactionmatchedbyapreviousACK
isconsideredaretransmissionofthatpreviousACK.
|Requestreceived
|passtoTU
V
++
||
|Trying|+
|||
++|200699fromTU
||sendresponse
|1xxfromTU|
|sendresponse|
||
RequestV1xxfromTU|
sendresponse++sendresponse|
+||+|
||Proceeding|||
+>||<+|
+<|||
|TrnsprtErr++|
|InformTU||
|||
||200699fromTU|
||sendresponse|
|RequestV|
|sendresponse++|
|+|||
|||Completed|<+
|+>||
+<||
|TrnsprtErr++
|InformTU|
||TimerJfires
||
||
|V
|++
|||
+>|Terminated|
||
++
Figure8:nonINVITEservertransaction
Forallotherrequestmethods,arequestismatchedtoatransaction
iftheRequestURI,Totag,Fromtag,CallID,CSeq(includingthe
method),andtopViaheaderfieldmatchthoseoftherequestthat
createdthetransaction.Matchingisdonebasedonthematching
rulesdefinedforeachofthoseheaderfields.WhenanonINVITE
requestmatchesanexistingtransaction,itisaretransmissionof
therequestthatcreatedthattransaction.
BecausethematchingrulesincludetheRequestURI,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
thecaseofconnectionorientedtransports.
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.
ItisRECOMMENDEDthatconnectionsbekeptopenforsome
implementationdefineddurationafterthelastmessagewassentor
receivedoverthatconnection.ThisdurationSHOULDatleastequal
thelongestamountoftimetheelementwouldneedinordertobringa
transactionfrominstantiationtotheterminatedstate.Thisisto
makeitlikelythattransactionsarecompletedoverthesame
connectiononwhichtheyareinitiated(forexample,request,
response,andinthecaseofINVITE,ACKfornon2xxresponses).
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.ThishappensduetotheadditionofRecordRoute
headerfieldvaluestotheresponsestoINVITE,forexample.With
theextrabuffer,theresponsecanbeabout170byteslargerthan
therequest,andstillnotbefragmentedonIPv4(about30bytes
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"singlehopdiscoverylike"
service,deliveringarequesttoagroupofhomogeneousservers,
whereitisonlyrequiredtoprocesstheresponsefromanyoneof
them.Thisfunctionalityismostusefulforregistrations.Infact,
basedonthetransactionprocessingrulesinSection17.1.3,the
clienttransactionwillacceptthefirstresponse,andviewany
othersasretransmissionsbecausetheyallcontainthesameVia
branchidentifier.
Beforearequestissent,theclienttransportMUSTinsertavalueof
the"sentby"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"sentby"field.Italso
MUSTbepreparedtoreceiveincomingconnectionsonanyaddressand
portthatwouldbeselectedbyaserverbasedontheprocedures
describedinSection5of[4].
Forunreliableunicasttransports,theclienttransportMUSTbe
preparedtoreceiveresponsesonthesourceIPaddressfromwhichthe
requestissent(asresponsesaresentbacktothesourceaddress)
andtheportnumberinthe"sentby"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"sentby"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).
18.2Servers
18.2.1ReceivingRequests
AserverSHOULDbepreparedtoreceiverequestsonanyIPaddress,
portandtransportcombinationthatcanbetheresultofaDNSlookup
onaSIPorSIPSURI[4]thatishandedoutforthepurposesof
communicatingwiththatserver.Inthiscontext,"handingout"
includesplacingaURIinaContactheaderfieldinaREGISTER
requestoraredirectresponse,orinaRecordRouteheaderfieldin
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"sentby"parameterinthetopVia
headerfieldvalue.Ifthehostportionofthe"sentby"parameter
containsadomainname,orifitcontainsanIPaddressthatdiffers
fromthepacketsourceaddress,theserverMUSTadda"received"
parametertothatViaheaderfieldvalue.ThisparameterMUST
containthesourceaddressfromwhichthepacketwasreceived.This
istoassisttheservertransportlayerinsendingtheresponse,
sinceitmustbesenttothesourceIPaddressfromwhichtherequest
came.
Considerarequestreceivedbytheservertransportwhichlookslike,
inpart:
INVITEsip:bob@Biloxi.comSIP/2.0
Via:SIP/2.0/UDPbobspc.biloxi.com:5060
TherequestisreceivedwithasourceIPaddressof192.0.2.4.
Beforepassingtherequestup,thetransportaddsa"received"
parameter,sothattherequestwouldlooklike,inpart:
INVITEsip:bob@Biloxi.comSIP/2.0
Via:SIP/2.0/UDPbobspc.biloxi.com:5060received=192.0.2.4
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"sentprotocol"isareliabletransportprotocolsuchas
TCPorSCTP,orTLSoverthose,theresponseMUSTbesentusing
theexistingconnectiontothesourceoftheoriginalrequest
thatcreatedthetransaction,ifthatconnectionisstillopen.
Thisrequirestheservertransporttomaintainanassociation
betweenservertransactionsandtransportconnections.Ifthat
connectionisnolongeropen,theserverSHOULDopena
connectiontotheIPaddressinthe"received"parameter,if
present,usingtheportinthe"sentby"value,orthedefault
portforthattransport,ifnoportisspecified.Ifthat
connectionattemptfails,theserverSHOULDusetheprocedures
in[4]forserversinordertodeterminetheIPaddressand
porttoopentheconnectionandsendtheresponseto.
oOtherwise,iftheViaheaderfieldvaluecontainsa"maddr"
parameter,theresponseMUSTbeforwardedtotheaddresslisted
there,usingtheportindicatedin"sentby",orport5060if
noneispresent.Iftheaddressisamulticastaddress,the
responseSHOULDbesentusingtheTTLindicatedinthe"ttl"
parameter,orwithaTTLof1ifthatparameterisnotpresent.
oOtherwise(forunreliableunicasttransports),ifthetopVia
hasa"received"parameter,theresponseMUSTbesenttothe
addressinthe"received"parameter,usingtheportindicated
inthe"sentby"value,orusingport5060ifnoneisspecified
explicitly.Ifthisfails,forexample,elicitsanICMP"port
unreachable"response,theproceduresofSection5of[4]
SHOULDbeusedtodeterminewheretosendtheresponse.
oOtherwise,ifitisnotreceivertagged,theresponseMUSTbe
senttotheaddressindicatedbythe"sentby"value,usingthe
proceduresinSection5of[4].
18.3Framing
Inthecaseofmessageorientedtransports(suchasUDP),ifthe
messagehasaContentLengthheaderfield,themessagebodyis
assumedtocontainthatmanybytes.Ifthereareadditionalbytesin
thetransportpacketbeyondtheendofthebody,theyMUSTbe
discarded.Ifthetransportpacketendsbeforetheendofthe
messagebody,thisisconsideredanerror.Ifthemessageisa
response,itMUSTbediscarded.Ifthemessageisarequest,the
elementSHOULDgeneratea400(BadRequest)response.Ifthemessage
hasnoContentLengthheaderfield,themessagebodyisassumedto
endattheendofthetransportpacket.
InthecaseofstreamorientedtransportssuchasTCP,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.
19.1SIPandSIPSUniformResourceIndicators
ASIPorSIPSURIidentifiesacommunicationsresource.Likeall
URIs,SIPandSIPSURIsmaybeplacedinwebpages,emailmessages,
orprintedliterature.Theycontainsufficientinformationto
initiateandmaintainacommunicationsessionwiththeresource.
Examplesofcommunicationsresourcesincludethefollowing:
oauserofanonlineservice
oanappearanceonamultilinephone
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
ofSIPrequestheaderfieldsandtheSIPmessagebody.Thismakesit
possibletospecifythesubject,mediatype,orurgencyofsessions
initiatedbyusingaURIonawebpageorinanemailmessage.The
formalsyntaxforaSIPorSIPSURIispresentedinSection25.Its
generalform,inthecaseofaSIPURI,is:
sip:user:password@host:porturiparameters?headers
TheformatforaSIPSURIisthesame,exceptthattheschemeis
"sips"insteadofsip.Thesetokens,andsomeofthetokensintheir
expansions,havethefollowingmeanings:
user:Theidentifierofaparticularresourceatthehostbeing
addressed.Theterm"host"inthiscontextfrequentlyrefers
toadomain.The"userinfo"ofaURIconsistsofthisuser
field,thepasswordfield,andthe@signfollowingthem.The
userinfopartofaURIisoptionalandMAYbeabsentwhenthe
destinationhostdoesnothaveanotionofusersorwhenthe
hostitselfistheresourcebeingidentified.Ifthe@signis
presentinaSIPorSIPSURI,theuserfieldMUSTNOTbeempty.
Ifthehostbeingaddressedcanprocesstelephonenumbers,for
instance,anInternettelephonygateway,atelephone
subscriberfielddefinedinRFC2806[9]MAYbeusedto
populatetheuserfield.Therearespecialescapingrulesfor
encodingtelephonesubscriberfieldsinSIPandSIPSURIs
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
eitherafullyqualifieddomainnameornumericIPv4orIPv6
address.Usingthefullyqualifieddomainnameformis
RECOMMENDEDwheneverpossible.
port:Theportnumberwheretherequestistobesent.
URIparameters:Parametersaffectingarequestconstructedfrom
theURI.
URIparametersareaddedafterthehostportcomponentandare
separatedbysemicolons.
URIparameterstaketheform:
parametername"="parametervalue
EventhoughanarbitrarynumberofURIparametersmaybe
includedinaURI,anygivenparameternameMUSTNOTappear
morethanonce.
Thisextensiblemechanismincludesthetransport,maddr,ttl,
user,methodandlrparameters.
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
traversedenroutetothedestination.Continuingtousethe
maddrparameterthiswayisstronglydiscouraged(the
mechanismsthatenableitaredeprecated).Implementations
shouldinsteadusetheRoutemechanismdescribedinthis
document,establishingapreexistingroutesetifnecessary
(seeSection8.1.1.1).ThisprovidesafullURItodescribe
thenodetobetraversed.
ThettlparameterdeterminesthetimetolivevalueoftheUDP
multicastpacketandMUSTonlybeusedifmaddrisamulticast
addressandthetransportprotocolisUDP.Forexample,to
specifyacalltoalice@atlanta.comusingmulticastto
239.255.255.1withattlof15,thefollowingURIwouldbe
used:
sip:alice@atlanta.commaddr=239.255.255.1ttl=15
Thesetofvalidtelephonesubscriberstringsisasubsetof
validuserstrings.TheuserURIparameterexiststo
distinguishtelephonenumbersfromusernamesthathappento
lookliketelephonenumbers.Iftheuserstringcontainsa
telephonenumberformattedasatelephonesubscriber,theuser
parametervalue"phone"SHOULDbepresent.Evenwithoutthis
parameter,recipientsofSIPandSIPSURIsMAYinterpretthe
pre@partasatelephonenumberiflocalrestrictionsonthe
namespaceforusernameallowit.
ThemethodoftheSIPrequestconstructedfromtheURIcanbe
specifiedwiththemethodparameter.
Thelrparameter,whenpresent,indicatesthattheelement
responsibleforthisresourceimplementstheroutingmechanisms
specifiedinthisdocument.Thisparameterwillbeusedinthe
URIsproxiesplaceintoRecordRouteheaderfieldvalues,and
mayappearintheURIsinapreexistingrouteset.
Thisparameterisusedtoachievebackwardscompatibilitywith
systemsimplementingthestrictroutingmechanismsofRFC2543
andtherfc2543bisdraftsuptobis05.Anelementpreparing
tosendarequestbasedonaURInotcontainingthisparameter
canassumethereceivingelementimplementsstrictroutingand
reformatthemessagetopreservetheinformationinthe
RequestURI.
Sincetheuriparametermechanismisextensible,SIPelements
MUSTsilentlyignoreanyuriparametersthattheydonot
understand.
Headers:Headerfieldstobeincludedinarequestconstructed
fromtheURI.
HeadersfieldsintheSIPrequestcanbespecifiedwiththe"?"
mechanismwithinaURI.Theheadernamesandvaluesare
encodedinampersandseparatedhname=hvaluepairs.The
specialhname"body"indicatesthattheassociatedhvalueis
themessagebodyoftheSIPrequest.
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).
19.1.2CharacterEscapingRequirements
dialog
reg./redir.Contact/
defaultReq.URIToFromContactRR/Routeexternal
useroooooo
passwordoooooo
hostmmmmmm
port(1)oooo
userparamipoooooo
methodINVITEo
maddrparamoooo
ttlparam1ooo
transp.param(2)oooo
lrparamooo
otherparamoooooo
headersoo
(1):Thedefaultportvalueistransportandschemedependent.The
defaultis5060forsip:usingUDP,TCP,orSCTP.Thedefaultis
5061forsip:usingTLSoverTCPandsips:overTCP.
(2):Thedefaulttransportisschemedependent.Forsip:,itisUDP.
Forsips:,itisTCP.
Table1:UseanddefaultvaluesofURIcomponentsforSIPheader
fieldvalues,RequestURIandreferences
SIPfollowstherequirementsandguidelinesofRFC2396[5]when
definingthesetofcharactersthatmustbeescapedinaSIPURI,and
usesits""%"HEXHEX"mechanismforescaping.FromRFC2396[5]:
ThesetofcharactersactuallyreservedwithinanygivenURI
componentisdefinedbythatcomponent.Ingeneral,acharacter
isreservedifthesemanticsoftheURIchangesifthecharacter
isreplacedwithitsescapedUSASCIIencoding[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".
ExpandingthehnameandhvaluetokensinSection25showthatallURI
reservedcharactersinheaderfieldnamesandvaluesMUSTbeescaped.
Thetelephonesubscribersubsetoftheusercomponenthasspecial
escapingconsiderations.Thesetofcharactersnotreservedinthe
RFC2806[9]descriptionoftelephonesubscribercontainsanumberof
charactersinvarioussyntaxelementsthatneedtobeescapedwhen
usedinSIPURIs.Anycharactersoccurringinatelephonesubscriber
thatdonotappearinanexpansionoftheBNFfortheuserruleMUST
beescaped.
Notethatcharacterescapingisnotallowedinthehostcomponentof
aSIPorSIPSURI(the%characterisnotvalidinitsexpansion).
Thisislikelytochangeinthefutureasrequirementsfor
InternationalizedDomainNamesarefinalized.Current
implementationsMUSTNOTattempttoimproverobustnessbytreating
receivedescapedcharactersinthehostcomponentasliterally
equivalenttotheirunescapedcounterpart.Thebehaviorrequiredto
meettherequirementsofIDNmaybesignificantlydifferent.
19.1.3ExampleSIPandSIPSURIs
sip:alice@atlanta.com
sip:alice:secretword@atlanta.comtransport=tcp
sips:alice@atlanta.com?subject=project%20x&priority=urgent
sip:+12125551212:1234@gateway.comuser=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.commethod=REGISTER?to=alice%40atlanta.com
sip:aliceday=tuesday@atlanta.com
ThelastsampleURIabovehasauserfieldvalueof
"aliceday=tuesday".Theescapingrulesdefinedaboveallowa
semicolontoappearunescapedinthisfield.Forthepurposesof
thisprotocol,thefieldisopaque.Thestructureofthatvalueis
onlyusefultotheSIPelementresponsiblefortheresource.
19.1.4URIComparison
Someoperationsinthisspecificationrequiredeterminingwhethertwo
SIPorSIPSURIsareequivalent.Inthisspecification,registrars
needtocomparebindingsinContactURIsinREGISTERrequests(see
Section10.3.).SIPandSIPSURIsarecomparedforequality
accordingtothefollowingrules:
oASIPandSIPSURIareneverequivalent.
oComparisonoftheuserinfoofSIPandSIPSURIsiscase
sensitive.Thisincludesuserinfocontainingpasswordsor
formattedastelephonesubscribers.Comparisonofallother
componentsoftheURIiscaseinsensitiveunlessexplicitly
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.
Thesameistrueforthetransportparameter,ttlparameter,
userparameter,andmethodcomponents.
Definingsip:user@hosttonotbeequivalentto
sip:user@host:5060isachangefromRFC2543.Whenderiving
addressesfromURIs,equivalentaddressesareexpectedfrom
equivalentURIs.TheURIsip:user@host:5060willalways
resolvetoport5060.TheURIsip:user@hostmayresolveto
otherportsthroughtheDNSSRVmechanismsdetailedin[4].
oURIuriparametercomponentsarecomparedasfollows:
AnyuriparameterappearinginbothURIsmustmatch.
Auser,ttl,ormethoduriparameterappearinginonlyone
URInevermatches,evenifitcontainsthedefaultvalue.
AURIthatincludesanmaddrparameterwillnotmatchaURI
thatcontainsnomaddrparameter.
AllotheruriparametersappearinginonlyoneURIare
ignoredwhencomparingtheURIs.
oURIheadercomponentsareneverignored.Anypresentheader
componentMUSTbepresentinbothURIsandmatchfortheURIs
tomatch.Thematchingrulesaredefinedforeachheaderfield
inSection20.
TheURIswithineachofthefollowingsetsareequivalent:
sip:%61lice@atlanta.comtransport=TCP
sip:alice@AtLanTa.CoMTransport=tcp
sip:carol@chicago.com
sip:carol@chicago.comnewparam=5
sip:carol@chicago.comsecurity=on
sip:biloxi.comtransport=tcpmethod=REGISTER?to=sip:bob%40biloxi.com
sip:biloxi.commethod=REGISTERtransport=tcp?to=sip:bob%40biloxi.com
sip:alice@atlanta.com?subject=project%20x&priority=urgent
sip:alice@atlanta.com?priority=urgent&subject=project%20x
TheURIswithineachofthefollowingsetsarenotequivalent:
SIP:ALICE@AtLanTa.CoMTransport=udp(differentusernames)
sip:alice@AtLanTa.CoMTransport=UDP
sip:bob@biloxi.com(canresolvetodifferentports)
sip:bob@biloxi.com:5060
sip:bob@biloxi.com(canresolvetodifferenttransports)
sip:bob@biloxi.comtransport=udp
sip:bob@biloxi.com(canresolvetodifferentportandtransports)
sip:bob@biloxi.com:6000transport=tcp
sip:carol@chicago.com(differentheadercomponent)
sip:carol@chicago.com?Subject=next%20meeting
sip:bob@phone21.boxesbybob.com(eventhoughthat'swhat
sip:bob@192.0.2.4phone21.boxesbybob.comresolvesto)
Notethatequalityisnottransitive:
osip:carol@chicago.comandsip:carol@chicago.comsecurity=onare
equivalent
osip:carol@chicago.comandsip:carol@chicago.comsecurity=off
areequivalent
osip:carol@chicago.comsecurity=onand
sip:carol@chicago.comsecurity=offarenotequivalent
19.1.5FormingRequestsfromaURI
Animplementationneedstotakecarewhenformingrequestsdirectly
fromaURI.URIsfrombusinesscards,webpages,andevenfrom
sourcesinsidetheprotocolsuchasregisteredcontactsmaycontain
inappropriateheaderfieldsorbodyparts.
AnimplementationMUSTincludeanyprovidedtransport,maddr,ttl,or
userparameterintheRequestURIoftheformedrequest.IftheURI
containsamethodparameter,itsvalueMUSTbeusedasthemethodof
therequest.ThemethodparameterMUSTNOTbeplacedinthe
RequestURI.UnknownURIparametersMUSTbeplacedinthemessage's
RequestURI.
AnimplementationSHOULDtreatthepresenceofanyheadersorbody
partsintheURIasadesiretoincludetheminthemessage,and
choosetohonortherequestonapercomponentbasis.
AnimplementationSHOULDNOThonortheseobviouslydangerousheader
fields:From,CallID,CSeq,Via,andRecordRoute.
AnimplementationSHOULDNOThonoranyrequestedRouteheaderfield
valuesinordertonotbeusedasanunwittingagentinmalicious
attacks.
AnimplementationSHOULDNOThonorrequeststoincludeheaderfields
thatmaycauseittofalselyadvertiseitslocationorcapabilities.
Theseinclude:Accept,AcceptEncoding,AcceptLanguage,Allow,
Contact(initsdialogusage),Organization,Supported,andUser
Agent.
AnimplementationSHOULDverifytheaccuracyofanyrequested
descriptiveheaderfields,including:ContentDisposition,Content
Encoding,ContentLanguage,ContentLength,ContentType,Date,
MimeVersion,andTimestamp.
IftherequestformedfromconstructingamessagefromagivenURIis
notavalidSIPrequest,theURIisinvalid.AnimplementationMUST
NOTproceedwithtransmittingtherequest.Itshouldinsteadpursue
thecourseofactiondueaninvalidURIinthecontextitoccurs.
Theconstructedrequestcanbeinvalidinmanyways.These
include,butarenotlimitedto,syntaxerrorinheaderfields,
invalidcombinationsofURIparameters,oranincorrect
descriptionofthemessagebody.
SendingarequestformedfromagivenURImayrequirecapabilities
unavailabletotheimplementation.TheURImightindicateuseofan
unimplementedtransportorextension,forexample.Animplementation
SHOULDrefusetosendtheserequestsratherthanmodifyingthemto
matchtheircapabilities.AnimplementationMUSTNOTsendarequest
requiringanextensionthatitdoesnotsupport.
Forexample,sucharequestcanbeformedthroughthepresenceof
aRequireheaderparameteroramethodURIparameterwithan
unknownorexplicitlyunsupportedvalue.
19.1.6RelatingSIPURIsandtelURLs
WhenatelURL(RFC2806[9])isconvertedtoaSIPorSIPSURI,the
entiretelephonesubscriberportionofthetelURL,includingany
parameters,isplacedintotheuserinfopartoftheSIPorSIPSURI.
Thus,tel:+3585551234567postd=pp22becomes
sip:+3585551234567postd=pp22@foo.comuser=phone
or
sips:+3585551234567postd=pp22@foo.comuser=phone
not
sip:+3585551234567@foo.compostd=pp22user=phone
or
sips:+3585551234567@foo.compostd=pp22user=phone
Ingeneral,equivalent"tel"URLsconvertedtoSIPorSIPSURIsin
thisfashionmaynotproduceequivalentSIPorSIPSURIs.The
userinfoofSIPandSIPSURIsarecomparedasacasesensitive
string.VarianceincaseinsensitiveportionsoftelURLsand
reorderingoftelURLparametersdoesnotaffecttelURLequivalence,
butdoesaffecttheequivalenceofSIPURIsformedfromthem.
Forexample,
tel:+3585551234567postd=pp22
tel:+3585551234567POSTD=PP22
areequivalent,while
sip:+3585551234567POSTD=PP22@foo.comuser=phone
arenot.
Likewise,
tel:+3585551234567postd=pp22isub=1411
tel:+3585551234567isub=1411postd=pp22
areequivalent,while
sip:+3585551234567postd=pp22isub=1411@foo.comuser=phone
sip:+3585551234567isub=1411postd=pp22@foo.comuser=phone
arenot.
Tomitigatethisproblem,elementsconstructingtelephonesubscriber
fieldstoplaceintheuserinfopartofaSIPorSIPSURISHOULDfold
anycaseinsensitiveportionoftelephonesubscribertolowercase,
andorderthetelephonesubscriberparameterslexicallybyparameter
name,exceptingisdnsubaddressandpostdial,whichoccurfirstand
inthatorder.(AllcomponentsofatelURLexceptforfuture
extensionparametersaredefinedtobecomparedcaseinsensitive.)
Followingthissuggestion,both
tel:+3585551234567postd=pp22
tel:+3585551234567POSTD=PP22
become
andboth
tel:+3585551234567tsp=a.bphonecontext=5
tel:+3585551234567phonecontext=5tsp=a.b
become
sip:+3585551234567phonecontext=5tsp=a.b@foo.comuser=phone
19.2OptionTags
Optiontagsareuniqueidentifiersusedtodesignatenewoptions
(extensions)inSIP.ThesetagsareusedinRequire(Section20.32),
ProxyRequire(Section20.29),Supported(Section20.37)and
Unsupported(Section20.40)headerfields.Notethattheseoptions
appearasparametersinthoseheaderfieldsinanoptiontag=token
form(seeSection25forthedefinitionoftoken).
OptiontagsaredefinedinstandardstrackRFCs.Thisisachange
frompastpractice,andisinstitutedtoensurecontinuingmulti
vendorinteroperability(seediscussioninSection20.32andSection
20.37).AnIANAregistryofoptiontagsisusedtoensureeasy
reference.
19.3Tags
The"tag"parameterisusedintheToandFromheaderfieldsofSIP
messages.Itservesasageneralmechanismtoidentifyadialog,
whichisthecombinationoftheCallIDalongwithtwotags,onefrom
eachparticipantinthedialog.WhenaUAsendsarequestoutsideof
adialog,itcontainsaFromtagonly,providing"half"ofthedialog
ID.Thedialogiscompletedfromtheresponse(s),eachofwhich
contributesthesecondhalfintheToheaderfield.Theforkingof
SIPrequestsmeansthatmultipledialogscanbeestablishedfroma
singlerequest.Thisalsoexplainstheneedforthetwosideddialog
identifierwithoutacontributionfromtherecipients,the
originatorcouldnotdisambiguatethemultipledialogsestablished
fromasinglerequest.
WhenatagisgeneratedbyaUAforinsertionintoarequestor
response,itMUSTbegloballyuniqueandcryptographicallyrandom
withatleast32bitsofrandomness.Apropertyofthisselection
requirementisthataUAwillplaceadifferenttagintotheFrom
headerofanINVITEthanitwouldplaceintotheToheaderofthe
responsetothesameINVITE.ThisisneededinorderforaUAto
inviteitselftoasession,acommoncasefor"hairpinning"ofcalls
inPSTNgateways.Similarly,twoINVITEsfordifferentcallswill
havedifferentFromtags,andtworesponsesfordifferentcallswill
havedifferentTotags.
Besidestherequirementforglobaluniqueness,thealgorithmfor
generatingatagisimplementationspecific.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.
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:Conditionalrequirementsontheheaderfielddependonthe
contextofthemessage.
m:Theheaderfieldismandatory.
m*:TheheaderfieldSHOULDbesent,butclients/serversneedto
bepreparedtoreceivemessageswithoutthatheaderfield.
o:Theheaderfieldisoptional.
t:TheheaderfieldSHOULDbesent,butclients/serversneedtobe
preparedtoreceivemessageswithoutthatheaderfield.
Ifastreambasedprotocol(suchasTCP)isusedasa
transport,thentheheaderfieldMUSTbesent.
*: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(<and>).AnyURIparametersare
containedwithinthesebrackets.IftheURIisnotenclosedinangle
brackets,anysemicolondelimitedparametersareheaderparameters,
notURIparameters.
20.1Accept
TheAcceptheaderfieldfollowsthesyntaxdefinedin[H14.1].The
semanticsarealsoidentical,withtheexceptionthatifnoAccept
headerfieldispresent,theserverSHOULDassumeadefaultvalueof
application/sdp.
AnemptyAcceptheaderfieldmeansthatnoformatsareacceptable.
Example:
HeaderfieldwhereproxyACKBYECANINVOPTREG
___________________________________________________________
AcceptRoom*o
Accept2xxom*o
Accept415cccc
AcceptEncodingRoooo
AcceptEncoding2xxom*o
AcceptEncoding415cccc
AcceptLanguageRoooo
AcceptLanguage2xxom*o
AcceptLanguage415cccc
AlertInfoRaro
AlertInfo180aro
AllowRoooo
Allow2xxom*m*o
Allowroooo
Allow405mmmm
AuthenticationInfo2xxoooo
AuthorizationRoooooo
CallIDcrmmmmmm
CallInfoarooo
ContactRomoo
Contact1xxo
Contact2xxmoo
Contact3xxdoooo
Contact485oooo
ContentDispositionooooo
ContentEncodingooooo
ContentLanguageooooo
ContentLengthartttttt
ContentType*****
CSeqcrmmmmmm
Dateaoooooo
ErrorInfo300699aooooo
Expiresoo
Fromcrmmmmmm
InReplyToRo
MaxForwardsRamrmmmmmm
MinExpires423m
MIMEVersionooooo
Organizationarooo
Table2:Summaryofheaderfields,AO
HeaderfieldwhereproxyACKBYECANINVOPTREG
___________________________________________________________________
PriorityRaro
ProxyAuthenticate407armmmm
ProxyAuthenticate401arooooo
ProxyAuthorizationRdrooooo
ProxyRequireRaroooo
RecordRouteRarooooo
RecordRoute2xx,18xmroooo
ReplyToo
Requirearcccc
RetryAfter404,413,480,486ooooo
500,503ooooo
600,603ooooo
RouteRadrcccccc
Serverrooooo
SubjectRo
SupportedRoom*oo
Supported2xxoom*m*o
Timestampoooooo
Toc(1)rmmmmmm
Unsupported420mmmm
UserAgentoooooo
ViaRamrmmmmmm
Viarcdrmmmmmm
Warningrooooo
WWWAuthenticate401armmmm
WWWAuthenticate407aroooo
Table3:Summaryofheaderfields,PZ(1):copiedwithpossible
additionoftag
Accept:application/sdplevel=1,application/xprivate,text/html
20.2AcceptEncoding
TheAcceptEncodingheaderfieldissimilartoAccept,butrestricts
thecontentcodings[H3.5]thatareacceptableintheresponse.See
[H14.3].ThesemanticsinSIPareidenticaltothosedefinedin
[H14.3].
AnemptyAcceptEncodingheaderfieldispermissible.Itis
equivalenttoAcceptEncoding:identity,thatis,onlytheidentity
encoding,meaningnoencoding,ispermissible.
IfnoAcceptEncodingheaderfieldispresent,theserverSHOULD
assumeadefaultvalueofidentity.
ThisdiffersslightlyfromtheHTTPdefinition,whichindicatesthat
whennotpresent,anyencodingcanbeused,buttheidentityencoding
ispreferred.
Example:
AcceptEncoding:gzip
20.3AcceptLanguage
TheAcceptLanguageheaderfieldisusedinrequeststoindicatethe
preferredlanguagesforreasonphrases,sessiondescriptions,or
statusresponsescarriedasmessagebodiesintheresponse.Ifno
AcceptLanguageheaderfieldispresent,theserverSHOULDassumeall
languagesareacceptabletotheclient.
TheAcceptLanguageheaderfieldfollowsthesyntaxdefinedin
[H14.4].Therulesfororderingthelanguagesbasedonthe"q"
parameterapplytoSIPaswell.
Example:
AcceptLanguage:da,engbq=0.8,enq=0.7
20.4AlertInfo
WhenpresentinanINVITErequest,theAlertInfoheaderfield
specifiesanalternativeringtonetotheUAS.Whenpresentina180
(Ringing)response,theAlertInfoheaderfieldspecifiesan
alternativeringbacktonetotheUAC.Atypicalusageisforaproxy
toinsertthisheaderfieldtoprovideadistinctiveringfeature.
TheAlertInfoheaderfieldcanintroducesecurityrisks.These
risksandthewaystohandlethemarediscussedinSection20.9,
whichdiscussestheCallInfoheaderfieldsincetherisksare
identical.
Inaddition,auserSHOULDbeabletodisablethisfeature
selectively.
Thishelpspreventdisruptionsthatcouldresultfromtheuseof
thisheaderfieldbyuntrustedelements.
Example:
AlertInfo:<http://www.example.com/sounds/moo.wav>
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.6AuthenticationInfo
TheAuthenticationInfoheaderfieldprovidesformutual
authenticationwithHTTPDigest.AUASMAYincludethisheaderfield
ina2xxresponsetoarequestthatwassuccessfullyauthenticated
usingdigestbasedontheAuthorizationheaderfield.
SyntaxandsemanticsfollowthosespecifiedinRFC2617[17].
Example:
AuthenticationInfo:nextnonce="47364c23432d2e131a5fb210812c"
20.7Authorization
TheAuthorizationheaderfieldcontainsauthenticationcredentialsof
aUA.Section22.2overviewstheuseoftheAuthorizationheader
field,andSection22.4describesthesyntaxandsemanticswhenused
withHTTPauthentication.
Thisheaderfield,alongwithProxyAuthorization,breaksthegeneral
rulesaboutmultipleheaderfieldvalues.Althoughnotacomma
separatedlist,thisheaderfieldnamemaybepresentmultipletimes,
andMUSTNOTbecombinedintoasingleheaderlineusingtheusual
rulesdescribedinSection7.3.
Intheexamplebelow,therearenoquotesaroundtheDigest
parameter:
Authorization:Digestusername="Alice",realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
20.8CallID
TheCallIDheaderfielduniquelyidentifiesaparticularinvitation
orallregistrationsofaparticularclient.Asinglemultimedia
conferencecangiverisetoseveralcallswithdifferentCallIDs,
forexample,ifauserinvitesasingleindividualseveraltimesto
thesame(longrunning)conference.CallIDsarecasesensitiveand
aresimplycomparedbytebybyte.
ThecompactformoftheCallIDheaderfieldisi.
Examples:
CallID:f81d4fae7dec11d0a76500a0c91e6bf6@biloxi.com
i:f81d4fae7dec11d0a76500a0c91e6bf6@192.0.2.4
20.9CallInfo
TheCallInfoheaderfieldprovidesadditionalinformationaboutthe
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.
UseoftheCallInfoheaderfieldcanposeasecurityrisk.Ifa
calleefetchestheURIsprovidedbyamaliciouscaller,thecallee
maybeatriskfordisplayinginappropriateoroffensivecontent,
dangerousorillegalcontent,andsoon.Therefore,itis
RECOMMENDEDthataUAonlyrendertheinformationintheCallInfo
headerfieldifitcanverifytheauthenticityoftheelementthat
originatedtheheaderfieldandtruststhatelement.Thisneednot
bethepeerUAaproxycaninsertthisheaderfieldintorequests.
Example:
CallInfo:<http://wwww.example.com/alice/photo.jpg>purpose=icon,
<http://www.example.com/alice/>purpose=info
20.10Contact
AContactheaderfieldvalueprovidesaURIwhosemeaningdependson
thetypeofrequestorresponseitisin.
AContactheaderfieldvaluecancontainadisplayname,aURIwith
URIparameters,andheaderparameters.
ThisdocumentdefinestheContactparameters"q"and"expires".
TheseparametersareonlyusedwhentheContactispresentina
REGISTERrequestorresponse,orina3xxresponse.Additional
parametersmaybedefinedinotherspecifications.
Whentheheaderfieldvaluecontainsadisplayname,theURI
includingallURIparametersisenclosedin"<"and">".Ifno"<"
and">"arepresent,allparametersaftertheURIareheader
parameters,notURIparameters.Thedisplaynamecanbetokens,ora
quotedstring,ifalargercharactersetisdesired.
Evenifthe"displayname"isempty,the"nameaddr"formMUSTbe
usedifthe"addrspec"containsacomma,semicolon,orquestion
mark.TheremayormaynotbeLWSbetweenthedisplaynameandthe
"<".
Theserulesforparsingadisplayname,URIandURIparameters,and
headerparametersalsoapplyfortheheaderfieldsToandFrom.
TheContactheaderfieldhasarolesimilartotheLocationheader
fieldinHTTP.However,theHTTPheaderfieldonlyallowsone
address,unquoted.SinceURIscancontaincommasandsemicolons
asreservedcharacters,theycanbemistakenforheaderor
parameterdelimiters,respectively.
ThecompactformoftheContactheaderfieldism(for"moved").
Examples:
Contact:"Mr.Watson"<sip:watson@worcester.belltelephone.com>
q=0.7expires=3600,
"Mr.Watson"<mailto:watson@belltelephone.com>q=0.1
m:<sips:bob@192.0.2.4>expires=60
20.11ContentDisposition
TheContentDispositionheaderfielddescribeshowthemessagebody
or,formultipartmessages,amessagebodypartistobeinterpreted
bytheUACorUAS.ThisSIPheaderfieldextendstheMIMEContent
Type(RFC2183[18]).
Severalnew"dispositiontypes"oftheContentDispositionheaderare
definedbySIP.Thevalue"session"indicatesthatthebodypart
describesasession,foreithercallsorearly(precall)media.The
value"render"indicatesthatthebodypartshouldbedisplayedor
otherwiserenderedtotheuser.Notethatthevalue"render"isused
ratherthan"inline"toavoidtheconnotationthattheMIMEbodyis
displayedasapartoftherenderingoftheentiremessage(sincethe
MIMEbodiesofSIPmessagesoftentimesarenotdisplayedtousers).
Forbackwardcompatibility,iftheContentDispositionheaderfield
ismissing,theserverSHOULDassumebodiesofContentType
application/sdparethedisposition"session",whileothercontent
typesare"render".
Thedispositiontype"icon"indicatesthatthebodypartcontainsan
imagesuitableasaniconicrepresentationofthecallerorcallee
thatcouldberenderedinformationallybyauseragentwhenamessage
hasbeenreceived,orpersistentlywhileadialogtakesplace.The
value"alert"indicatesthatthebodypartcontainsinformation,such
asanaudioclip,thatshouldberenderedbytheuseragentinan
attempttoalerttheusertothereceiptofarequest,generallya
requestthatinitiatesadialogthisalertingbodycouldforexample
berenderedasaringtoneforaphonecallaftera180Ringing
provisionalresponsehasbeensent.
AnyMIMEbodywitha"dispositiontype"thatrenderscontenttothe
usershouldonlybeprocessedwhenamessagehasbeenproperly
authenticated.
Thehandlingparameter,handlingparam,describeshowtheUASshould
reactifitreceivesamessagebodywhosecontenttypeordisposition
typeitdoesnotunderstand.Theparameterhasdefinedvaluesof
"optional"and"required".Ifthehandlingparameterismissing,the
value"required"SHOULDbeassumed.Thehandlingparameteris
describedinRFC3204[19].
Ifthisheaderfieldismissing,theMIMEtypedeterminesthedefault
contentdisposition.Ifthereisnone,"render"isassumed.
Example:
ContentDisposition:session
20.12ContentEncoding
TheContentEncodingheaderfieldisusedasamodifiertothe
"mediatype".Whenpresent,itsvalueindicateswhatadditional
contentcodingshavebeenappliedtotheentitybody,andthuswhat
decodingmechanismsMUSTbeappliedinordertoobtainthemediatype
referencedbytheContentTypeheaderfield.ContentEncodingis
primarilyusedtoallowabodytobecompressedwithoutlosingthe
identityofitsunderlyingmediatype.
Ifmultipleencodingshavebeenappliedtoanentitybody,the
contentcodingsMUSTbelistedintheorderinwhichtheywere
applied.
Allcontentcodingvaluesarecaseinsensitive.IANAactsasa
registryforcontentcodingvaluetokens.See[H3.5]fora
definitionofthesyntaxforcontentcoding.
ClientsMAYapplycontentencodingstothebodyinrequests.A
serverMAYapplycontentencodingstothebodiesinresponses.The
serverMUSTonlyuseencodingslistedintheAcceptEncodingheader
fieldintherequest.
ThecompactformoftheContentEncodingheaderfieldise.
Examples:
ContentEncoding:gzip
e:tar
20.13ContentLanguage
See[H14.12].Example:
ContentLanguage:fr
20.14ContentLength
TheContentLengthheaderfieldindicatesthesizeofthemessage
body,indecimalnumberofoctets,senttotherecipient.
ApplicationsSHOULDusethisfieldtoindicatethesizeofthe
messagebodytobetransferred,regardlessofthemediatypeofthe
entity.Ifastreambasedprotocol(suchasTCP)isusedas
transport,theheaderfieldMUSTbeused.
ThesizeofthemessagebodydoesnotincludetheCRLFseparating
headerfieldsandbody.AnyContentLengthgreaterthanorequalto
zeroisavalidvalue.Ifnobodyispresentinamessage,thenthe
ContentLengthheaderfieldvalueMUSTbesettozero.
TheabilitytoomitContentLengthsimplifiesthecreationof
cgilikescriptsthatdynamicallygenerateresponses.
Thecompactformoftheheaderfieldisl.
Examples:
ContentLength:349
l:173
20.15ContentType
TheContentTypeheaderfieldindicatesthemediatypeofthe
messagebodysenttotherecipient.The"mediatype"elementis
definedin[H3.7].TheContentTypeheaderfieldMUSTbepresentif
thebodyisnotempty.Ifthebodyisempty,andaContentType
headerfieldispresent,itindicatesthatthebodyofthespecific
typehaszerolength(forexample,anemptyaudiofile).
Thecompactformoftheheaderfieldisc.
Examples:
c:text/htmlcharset=ISO88594
20.16CSeq
ACSeqheaderfieldinarequestcontainsasingledecimalsequence
numberandtherequestmethod.ThesequencenumberMUSTbe
expressibleasa32bitunsignedinteger.ThemethodpartofCSeqis
casesensitive.TheCSeqheaderfieldservestoordertransactions
withinadialog,toprovideameanstouniquelyidentify
transactions,andtodifferentiatebetweennewrequestsandrequest
retransmissions.TwoCSeqheaderfieldsareconsideredequalifthe
sequencenumberandtherequestmethodareidentical.Example:
CSeq:4711INVITE
20.17Date
TheDateheaderfieldcontainsthedateandtime.UnlikeHTTP/1.1,
SIPonlysupportsthemostrecentRFC1123[20]formatfordates.As
in[H3.3],SIPrestrictsthetimezoneinSIPdateto"GMT",while
RFC1123allowsanytimezone.AnRFC1123dateiscasesensitive.
TheDateheaderfieldreflectsthetimewhentherequestorresponse
isfirstsent.
TheDateheaderfieldcanbeusedbysimpleendsystemswithouta
batterybackedclocktoacquireanotionofcurrenttime.
However,initsGMTform,itrequiresclientstoknowtheiroffset
fromGMT.
Example:
Date:Sat,13Nov201023:29:00GMT
20.18ErrorInfo
TheErrorInfoheaderfieldprovidesapointertoadditional
informationabouttheerrorstatusresponse.
SIPUACshaveuserinterfacecapabilitiesrangingfrompopup
windowsandaudioonPCsoftclientstoaudioonlyon"black"
phonesorendpointsconnectedviagateways.Ratherthanforcinga
servergeneratinganerrortochoosebetweensendinganerror
statuscodewithadetailedreasonphraseandplayinganaudio
recording,theErrorInfoheaderfieldallowsbothtobesent.
TheUACthenhasthechoiceofwhicherrorindicatortorenderto
thecaller.
AUACMAYtreataSIPorSIPSURIinanErrorInfoheaderfieldasif
itwereaContactinaredirectandgenerateanewINVITE,resulting
inarecordedannouncementsessionbeingestablished.AnonSIPURI
MAYberenderedtotheuser.
Examples:
SIP/2.0404Thenumberyouhavedialedisnotinservice
ErrorInfo:<sip:notinservicerecording@atlanta.com>
20.19Expires
TheExpiresheaderfieldgivestherelativetimeafterwhichthe
message(orcontent)expires.
Theprecisemeaningofthisismethoddependent.
TheexpirationtimeinanINVITEdoesnotaffectthedurationofthe
actualsessionthatmayresultfromtheinvitation.Session
descriptionprotocolsmayoffertheabilitytoexpresstimelimitson
thesessionduration,however.
Thevalueofthisfieldisanintegralnumberofseconds(indecimal)
between0and(2**32)1,measuredfromthereceiptoftherequest.
Example:
Expires:5
20.20From
TheFromheaderfieldindicatestheinitiatoroftherequest.This
maybedifferentfromtheinitiatorofthedialog.Requestssentby
thecalleetothecallerusethecallee'saddressintheFromheader
field.
Theoptional"displayname"ismeanttoberenderedbyahumanuser
interface.AsystemSHOULDusethedisplayname"Anonymous"ifthe
identityoftheclientistoremainhidden.Evenifthe"display
name"isempty,the"nameaddr"formMUSTbeusedifthe"addrspec"
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"<sip:agb@belltelephone.com>tag=a48s
From:sip:+12125551212@server.phone2net.comtag=887s
f:Anonymous<sip:c8oqz84zk7z@privacy.org>tag=hyh8
20.21InReplyTo
TheInReplyToheaderfieldenumeratestheCallIDsthatthiscall
referencesorreturns.TheseCallIDsmayhavebeencachedbythe
clientthenincludedinthisheaderfieldinareturncall.
Thisallowsautomaticcalldistributionsystemstoroutereturn
callstotheoriginatorofthefirstcall.Thisalsoallows
calleestofiltercalls,sothatonlyreturncallsforcallsthey
originatedwillbeaccepted.Thisfieldisnotasubstitutefor
requestauthentication.
Example:
InReplyTo:70710@saturn.belltel.com,17320@saturn.belltel.com
20.22MaxForwards
TheMaxForwardsheaderfieldmustbeusedwithanySIPmethodto
limitthenumberofproxiesorgatewaysthatcanforwardtherequest
tothenextdownstreamserver.Thiscanalsobeusefulwhenthe
clientisattemptingtotracearequestchainthatappearstobe
failingorloopinginmidchain.
TheMaxForwardsvalueisanintegerintherange0255indicating
theremainingnumberoftimesthisrequestmessageisallowedtobe
forwarded.Thiscountisdecrementedbyeachserverthatforwards
therequest.Therecommendedinitialvalueis70.
Thisheaderfieldshouldbeinsertedbyelementsthatcannot
otherwiseguaranteeloopdetection.Forexample,aB2BUAshould
insertaMaxForwardsheaderfield.
Example:
MaxForwards:6
20.23MinExpires
TheMinExpiresheaderfieldconveystheminimumrefreshinterval
supportedforsoftstateelementsmanagedbythatserver.This
includesContactheaderfieldsthatarestoredbyaregistrar.The
headerfieldcontainsadecimalintegernumberofsecondsfrom0to
(2**32)1.Theuseoftheheaderfieldina423(IntervalTooBrief)
responseisdescribedinSections10.2.8,10.3,and21.4.17.
Example:
MinExpires:60
20.24MIMEVersion
See[H19.4.1].
Example:
MIMEVersion:1.0
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"nonurgent","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:nonurgent
20.27ProxyAuthenticate
AProxyAuthenticateheaderfieldvaluecontainsanauthentication
challenge.
Theuseofthisheaderfieldisdefinedin[H14.33].SeeSection
22.3forfurtherdetailsonitsusage.
Example:
ProxyAuthenticate:Digestrealm="atlanta.com",
domain="sip:ss1.carrier.com",qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="",stale=FALSE,algorithm=MD5
20.28ProxyAuthorization
TheProxyAuthorizationheaderfieldallowstheclienttoidentify
itself(oritsuser)toaproxythatrequiresauthentication.A
ProxyAuthorizationfieldvalueconsistsofcredentialscontaining
theauthenticationinformationoftheuseragentfortheproxyand/or
realmoftheresourcebeingrequested.
SeeSection22.3foradefinitionoftheusageofthisheaderfield.
Thisheaderfield,alongwithAuthorization,breaksthegeneralrules
aboutmultipleheaderfieldnames.Althoughnotacommaseparated
list,thisheaderfieldnamemaybepresentmultipletimes,andMUST
NOTbecombinedintoasingleheaderlineusingtheusualrules
describedinSection7.3.1.
Example:
ProxyAuthorization:Digestusername="Alice",realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"
20.29ProxyRequire
TheProxyRequireheaderfieldisusedtoindicateproxysensitive
featuresthatmustbesupportedbytheproxy.SeeSection20.32for
moredetailsonthemechanicsofthismessageandausageexample.
Example:
ProxyRequire:foo
20.30RecordRoute
TheRecordRouteheaderfieldisinsertedbyproxiesinarequestto
forcefuturerequestsinthedialogtoberoutedthroughtheproxy.
ExamplesofitsusewiththeRouteheaderfieldaredescribedin
Sections16.12.1.
Example:
RecordRoute:<sip:server10.biloxi.comlr>,
<sip:bigbox3.site3.atlanta.comlr>
20.31ReplyTo
TheReplyToheaderfieldcontainsalogicalreturnURIthatmaybe
differentfromtheFromheaderfield.Forexample,theURIMAYbe
usedtoreturnmissedcallsorunestablishedsessions.Iftheuser
wishedtoremainanonymous,theheaderfieldSHOULDeitherbeomitted
fromtherequestorpopulatedinsuchawaythatdoesnotrevealany
privateinformation.
Evenifthe"displayname"isempty,the"nameaddr"formMUSTbe
usedifthe"addrspec"containsacomma,questionmark,or
semicolon.SyntaxissuesarediscussedinSection7.3.1.
Example:
ReplyTo:Bob<sip:bob@biloxi.com>
20.32Require
TheRequireheaderfieldisusedbyUACstotellUASsaboutoptions
thattheUACexpectstheUAStosupportinordertoprocessthe
request.Althoughanoptionalheaderfield,theRequireMUSTNOTbe
ignoredifitispresent.
TheRequireheaderfieldcontainsalistofoptiontags,describedin
Section19.2.EachoptiontagdefinesaSIPextensionthatMUSTbe
understoodtoprocesstherequest.Frequently,thisisusedto
indicatethataspecificsetofextensionheaderfieldsneedtobe
understood.AUACcomplianttothisspecificationMUSTonlyinclude
optiontagscorrespondingtostandardstrackRFCs.
Example:
Require:100rel
20.33RetryAfter
TheRetryAfterheaderfieldcanbeusedwitha500(ServerInternal
Error)or503(ServiceUnavailable)responsetoindicatehowlongthe
serviceisexpectedtobeunavailabletotherequestingclientand
witha404(NotFound),413(RequestEntityTooLarge),480
(TemporarilyUnavailable),486(BusyHere),600(Busy),or603
(Decline)responsetoindicatewhenthecalledpartyanticipates
beingavailableagain.Thevalueofthisfieldisapositiveinteger
numberofseconds(indecimal)afterthetimeoftheresponse.
Anoptionalcommentcanbeusedtoindicateadditionalinformation
aboutthetimeofcallback.Anoptional"duration"parameter
indicateshowlongthecalledpartywillbereachablestartingatthe
initialtimeofavailability.Ifnodurationparameterisgiven,the
serviceisassumedtobeavailableindefinitely.
Examples:
RetryAfter:18000duration=3600
RetryAfter:120(I'minameeting)
20.34Route
TheRouteheaderfieldisusedtoforceroutingforarequestthrough
thelistedsetofproxies.ExamplesoftheuseoftheRouteheader
fieldareinSection16.12.1.
Example:
Route:<sip:bigbox3.site3.atlanta.comlr>,
<sip:server10.biloxi.comlr>
20.35Server
TheServerheaderfieldcontainsinformationaboutthesoftwareused
bytheUAStohandletherequest.
Revealingthespecificsoftwareversionoftheservermightallowthe
servertobecomemorevulnerabletoattacksagainstsoftwarethatis
knowntocontainsecurityholes.ImplementersSHOULDmaketheServer
headerfieldaconfigurableoption.
Example:
Server:HomeServerv2
20.36Subject
TheSubjectheaderfieldprovidesasummaryorindicatesthenature
ofthecall,allowingcallfilteringwithouthavingtoparsethe
sessiondescription.Thesessiondescriptiondoesnothavetouse
thesamesubjectindicationastheinvitation.
ThecompactformoftheSubjectheaderfieldiss.
Example:
Subject:Needmoreboxes
s:TechSupport
20.37Supported
TheSupportedheaderfieldenumeratesalltheextensionssupportedby
theUACorUAS.
TheSupportedheaderfieldcontainsalistofoptiontags,described
inSection19.2,thatareunderstoodbytheUACorUAS.AUA
complianttothisspecificationMUSTonlyincludeoptiontags
correspondingtostandardstrackRFCs.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"displayname"ismeanttoberenderedbyahumanuser
interface.The"tag"parameterservesasageneralmechanismfor
dialogidentification.
SeeSection19.3fordetailsofthe"tag"parameter.
ComparisonofToheaderfieldsforequalityisidenticalto
comparisonofFromheaderfields.SeeSection20.10fortherules
forparsingadisplayname,URIandURIparameters,andheaderfield
parameters.
ThecompactformoftheToheaderfieldist.
ThefollowingareexamplesofvalidToheaderfields:
To:TheOperator<sip:operator@cs.columbia.edu>tag=287447
t:sip:+12125551212@server.phone2net.com
20.40Unsupported
TheUnsupportedheaderfieldliststhefeaturesnotsupportedbythe
UAS.SeeSection20.32formotivation.
Example:
Unsupported:foo
20.41UserAgent
TheUserAgentheaderfieldcontainsinformationabouttheUAC
originatingtherequest.Thesemanticsofthisheaderfieldare
definedin[H14.43].
Revealingthespecificsoftwareversionoftheuseragentmightallow
theuseragenttobecomemorevulnerabletoattacksagainstsoftware
thatisknowntocontainsecurityholes.ImplementersSHOULDmake
theUserAgentheaderfieldaconfigurableoption.
Example:
UserAgent:SoftphoneBeta1.5
20.42Via
TheViaheaderfieldindicatesthepathtakenbytherequestsofar
andindicatesthepaththatshouldbefollowedinroutingresponses.
ThebranchIDparameterintheViaheaderfieldvaluesservesasa
transactionidentifier,andisusedbyproxiestodetectloops.
AViaheaderfieldvaluecontainsthetransportprotocolusedtosend
themessage,theclient'shostnameornetworkaddress,andpossibly
theportnumberatwhichitwishestoreceiveresponses.AVia
headerfieldvaluecanalsocontainparameterssuchas"maddr",
"ttl","received",and"branch",whosemeaningandusearedescribed
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.belltelephone.com:5060branch=z9hG4bK87asdks7
Via:SIP/2.0/UDP192.0.2.1:5060received=192.0.2.207
branch=z9hG4bK77asjd
ThecompactformoftheViaheaderfieldisv.
Inthisexample,themessageoriginatedfromamultihomedhostwith
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:4000ttl=16
maddr=224.2.0.1branch=z9hG4bKa7c6a8dlze.1
Eventhoughthisspecificationmandatesthatthebranchparameterbe
presentinallrequests,theBNFfortheheaderfieldindicatesthat
itisoptional.ThisallowsinteroperationwithRFC2543elements,
whichdidnothavetoinsertthebranchparameter.
TwoViaheaderfieldsareequaliftheirsentprotocolandsentby
fieldsareequal,bothhavethesamesetofparameters,andthe
valuesofallparametersareequal.
20.43Warning
TheWarningheaderfieldisusedtocarryadditionalinformation
aboutthestatusofaresponse.Warningheaderfieldvaluesaresent
withresponsesandcontainathreedigitwarningcode,hostname,and
warningtext.
The"warntext"shouldbeinanaturallanguagethatismostlikely
tobeintelligibletothehumanuserreceivingtheresponse.This
decisioncanbebasedonanyavailableknowledge,suchasthe
locationoftheuser,theAcceptLanguagefieldinarequest,orthe
ContentLanguagefieldinaresponse.Thedefaultlanguageisi
default[21].
Thecurrentlydefined"warncode"sarelistedbelow,witha
recommendedwarntextinEnglishandadescriptionoftheirmeaning.
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).
370Insufficientbandwidth:Thebandwidthspecifiedinthesession
descriptionordefinedbythemediaexceedsthatknowntobe
available.
399Miscellaneouswarning:Thewarningtextcanincludearbitrary
informationtobepresentedtoahumanuserorlogged.A
systemreceivingthiswarningMUSTNOTtakeanyautomated
action.
1xxand2xxhavebeentakenbyHTTP/1.1.
Additional"warncode"scanbedefinedthroughIANA,asdefinedin
Section27.2.
Examples:
Warning:307isi.edu"Sessionparameter'foo'notunderstood"
Warning:301isi.edu"Incompatiblenetworkaddresstype'E.164'"
20.44WWWAuthenticate
AWWWAuthenticateheaderfieldvaluecontainsanauthentication
challenge.SeeSection22.2forfurtherdetailsonitsusage.
Example:
WWWAuthenticate: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.
21.1.1100Trying
Thisresponseindicatesthattherequesthasbeenreceivedbythe
nexthopserverandthatsomeunspecifiedactionisbeingtakenon
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,"5callsqueuedexpectedwaiting
timeis15minutes".TheserverMAYissueseveral182(Queued)
responsestoupdatethecalleraboutthestatusofthequeuedcall.
21.1.5183SessionProgress
The183(SessionProgress)responseisusedtoconveyinformation
abouttheprogressofthecallthatisnototherwiseclassified.The
ReasonPhrase,headerfields,ormessagebodyMAYbeusedtoconvey
moredetailsaboutthecallprogress.
21.2Successful2xx
Therequestwassuccessful.
21.2.1200OK
Therequesthassucceeded.Theinformationreturnedwiththe
responsedependsonthemethodusedintherequest.
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
TheusercannolongerbefoundattheaddressintheRequestURI,
andtherequestingclientSHOULDretryatthenewaddressgivenby
theContactheaderfield(Section20.10).TherequestorSHOULD
updateanylocaldirectories,addressbooks,anduserlocationcaches
withthisnewvalueandredirectfuturerequeststotheaddress(es)
listed.
21.3.3302MovedTemporarily
TherequestingclientSHOULDretrytherequestatthenewaddress(es)
givenbytheContactheaderfield(Section20.10).TheRequestURI
ofthenewrequestusesthevalueoftheContactheaderfieldinthe
response.
ThedurationofthevalidityoftheContactURIcanbeindicated
throughanExpires(Section20.19)headerfieldoranexpires
parameterintheContactheaderfield.BothproxiesandUAsMAY
cachethisURIforthedurationoftheexpirationtime.Ifthereis
noexplicitexpirationtime,theaddressisonlyvalidoncefor
recursing,andMUSTNOTbecachedforfuturetransactions.
IftheURIcachedfromtheContactheaderfieldfails,theRequest
URIfromtheredirectedrequestMAYbetriedagainasingletime.
ThetemporaryURImayhavebecomeoutofdatesoonerthanthe
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
ReasonPhraseSHOULDidentifythesyntaxprobleminmoredetail,for
example,"MissingCallIDheaderfield".
21.4.2401Unauthorized
Therequestrequiresuserauthentication.Thisresponseisissuedby
UASsandregistrars,while407(ProxyAuthenticationRequired)is
usedbyproxyservers.
21.4.3402PaymentRequired
Reservedforfutureuse.
21.4.4403Forbidden
Theserverunderstoodtherequest,butisrefusingtofulfillit.
Authorizationwillnothelp,andtherequestSHOULDNOTberepeated.
21.4.5404NotFound
Theserverhasdefinitiveinformationthattheuserdoesnotexistat
thedomainspecifiedintheRequestURI.Thisstatusisalso
returnedifthedomainintheRequestURIdoesnotmatchanyofthe
domainshandledbytherecipientoftherequest.
21.4.6405MethodNotAllowed
ThemethodspecifiedintheRequestLineisunderstood,butnot
allowedfortheaddressidentifiedbytheRequestURI.
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.
21.4.10410Gone
Therequestedresourceisnolongeravailableattheserverandno
forwardingaddressisknown.Thisconditionisexpectedtobe
consideredpermanent.Iftheserverdoesnotknow,orhasno
facilitytodetermine,whetherornottheconditionispermanent,the
statuscode404(NotFound)SHOULDbeusedinstead.
21.4.11413RequestEntityTooLarge
Theserverisrefusingtoprocessarequestbecausetherequest
entitybodyislargerthantheserveriswillingorabletoprocess.
TheserverMAYclosetheconnectiontopreventtheclientfrom
continuingtherequest.
Iftheconditionistemporary,theserverSHOULDincludeaRetry
Afterheaderfieldtoindicatethatitistemporaryandafterwhat
timetheclientMAYtryagain.
21.4.12414RequestURITooLong
TheserverisrefusingtoservicetherequestbecausetheRequestURI
islongerthantheserveriswillingtointerpret.
21.4.13415UnsupportedMediaType
Theserverisrefusingtoservicetherequestbecausethemessage
bodyoftherequestisinaformatnotsupportedbytheserverfor
therequestedmethod.TheserverMUSTreturnalistofacceptable
formatsusingtheAccept,AcceptEncoding,orAcceptLanguageheader
field,dependingonthespecificproblemwiththecontent.UAC
processingofthisresponseisdescribedinSection8.1.3.5.
21.4.14416UnsupportedURIScheme
TheservercannotprocesstherequestbecausetheschemeoftheURI
intheRequestURIisunknowntotheserver.Clientprocessingof
thisresponseisdescribedinSection8.1.3.5.
21.4.15420BadExtension
Theserverdidnotunderstandtheprotocolextensionspecifiedina
ProxyRequire(Section20.29)orRequire(Section20.32)header
field.TheserverMUSTincludealistoftheunsupportedextensions
inanUnsupportedheaderfieldintheresponse.UACprocessingof
thisresponseisdescribedinSection8.1.3.5.
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
andtherelatedMinExpiresheaderfieldaredescribedinSections
10.2.8,10.3,and20.23.
21.4.18480TemporarilyUnavailable
Thecallee'sendsystemwascontactedsuccessfullybutthecalleeis
currentlyunavailable(forexample,isnotloggedin,loggedinbut
inastatethatprecludescommunicationwiththecallee,orhas
activatedthe"donotdisturb"feature).TheresponseMAYindicatea
bettertimetocallintheRetryAfterheaderfield.Theusercould
alsobeavailableelsewhere(unbeknownsttothisserver).Thereason
phraseSHOULDindicateamoreprecisecauseastowhythecalleeis
unavailable.ThisvalueSHOULDbesettablebytheUA.Status486
(BusyHere)MAYbeusedtomorepreciselyindicateaparticular
reasonforthecallfailure.
Thisstatusisalsoreturnedbyaredirectorproxyserverthat
recognizestheuseridentifiedbytheRequestURI,butdoesnot
currentlyhaveavalidforwardinglocationforthatuser.
21.4.19481Call/TransactionDoesNotExist
ThisstatusindicatesthattheUASreceivedarequestthatdoesnot
matchanyexistingdialogortransaction.
21.4.20482LoopDetected
Theserverhasdetectedaloop(Section16.3Item4).
21.4.21483TooManyHops
TheserverreceivedarequestthatcontainsaMaxForwards(Section
20.22)headerfieldwiththevaluezero.
21.4.22484AddressIncomplete
TheserverreceivedarequestwithaRequestURIthatwasincomplete.
AdditionalinformationSHOULDbeprovidedinthereasonphrase.
Thisstatuscodeallowsoverlappeddialing.Withoverlapped
dialing,theclientdoesnotknowthelengthofthedialing
string.Itsendsstringsofincreasinglengths,promptingthe
userformoreinput,untilitnolongerreceivesa484(Address
Incomplete)statusresponse.
21.4.23485Ambiguous
TheRequestURIwasambiguous.TheresponseMAYcontainalistingof
possibleunambiguousaddressesinContactheaderfields.Revealing
alternativescaninfringeonprivacyoftheuserortheorganization.
ItMUSTbepossibletoconfigureaservertorespondwithstatus404
(NotFound)ortosuppressthelistingofpossiblechoicesfor
ambiguousRequestURIs.
ExampleresponsetoarequestwiththeRequestURI
sip:lee@example.com:
SIP/2.0485Ambiguous
Contact:CarolLee<sip:carol.lee@example.com>
Contact:PingLee<sip:p.lee@example.com>
Contact:LeeM.Foote<sips:lee.foote@example.com>
Someemailandvoicemailsystemsprovidethisfunctionality.A
statuscodeseparatefrom3xxisusedsincethesemanticsare
different:for300,itisassumedthatthesamepersonorservice
willbereachedbythechoicesprovided.Whileanautomated
choiceorsequentialsearchmakessensefora3xxresponse,user
interventionisrequiredfora485(Ambiguous)response.
21.4.24486BusyHere
Thecallee'sendsystemwascontactedsuccessfully,butthecalleeis
currentlynotwillingorabletotakeadditionalcallsatthisend
system.TheresponseMAYindicateabettertimetocallinthe
RetryAfterheaderfield.Theusercouldalsobeavailable
elsewhere,suchasthroughavoicemailservice.Status600(Busy
Everywhere)SHOULDbeusediftheclientknowsthatnootherend
systemwillbeabletoacceptthiscall.
21.4.25487RequestTerminated
TherequestwasterminatedbyaBYEorCANCELrequest.Thisresponse
isneverreturnedforaCANCELrequestitself.
21.4.26488NotAcceptableHere
Theresponsehasthesamemeaningas606(NotAcceptable),butonly
appliestothespecificresourceaddressedbytheRequestURIandthe
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
clientmayretrytherequestusingtheRetryAfterheaderfield.
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
indicatewhentheclientshouldretrytherequestinaRetryAfter
headerfield.IfnoRetryAfterisgiven,theclientMUSTactasif
ithadreceiveda500(ServerInternalError)response.
Aclient(proxyorUAC)receivinga503(ServiceUnavailable)SHOULD
attempttoforwardtherequesttoanalternateserver.ItSHOULDNOT
forwardanyotherrequeststothatserverforthedurationspecified
intheRetryAfterheaderfield,ifpresent.
ServersMAYrefusetheconnectionordroptherequestinsteadof
respondingwith503(ServiceUnavailable).
21.5.5504ServerTimeout
Theserverdidnotreceiveatimelyresponsefromanexternalserver
itaccessedinattemptingtoprocesstherequest.408(Request
Timeout)shouldbeusedinsteadiftherewasnoresponsewithinthe
periodspecifiedintheExpiresheaderfieldfromtheupstream
server.
21.5.6505VersionNotSupported
Theserverdoesnotsupport,orrefusestosupport,theSIPprotocol
versionthatwasusedintherequest.Theserverisindicatingthat
itisunableorunwillingtocompletetherequestusingthesame
majorversionastheclient,otherthanwiththiserrormessage.
21.5.7513MessageTooLarge
Theserverwasunabletoprocesstherequestsincethemessagelength
exceededitscapabilities.
21.6GlobalFailures6xx
6xxresponsesindicatethataserverhasdefinitiveinformationabout
aparticularuser,notjusttheparticularinstanceindicatedinthe
RequestURI.
21.6.1600BusyEverywhere
Thecallee'sendsystemwascontactedsuccessfullybutthecalleeis
busyanddoesnotwishtotakethecallatthistime.Theresponse
MAYindicateabettertimetocallintheRetryAfterheaderfield.
Ifthecalleedoesnotwishtorevealthereasonfordecliningthe
call,thecalleeusesstatuscode603(Decline)instead.Thisstatus
responseisreturnedonlyiftheclientknowsthatnootherendpoint
(suchasavoicemailsystem)willanswertherequest.Otherwise,
486(BusyHere)shouldbereturned.
21.6.2603Decline
Thecallee'smachinewassuccessfullycontactedbuttheuser
explicitlydoesnotwishtoorcannotparticipate.TheresponseMAY
indicateabettertimetocallintheRetryAfterheaderfield.This
statusresponseisreturnedonlyiftheclientknowsthatnoother
endpointwillanswertherequest.
21.6.3604DoesNotExistAnywhere
Theserverhasauthoritativeinformationthattheuserindicatedin
theRequestURIdoesnotexistanywhere.
21.6.4606NotAcceptable
Theuser'sagentwascontactedsuccessfullybutsomeaspectsofthe
sessiondescriptionsuchastherequestedmedia,bandwidth,or
addressingstylewerenotacceptable.
A606(NotAcceptable)responsemeansthattheuserwishesto
communicate,butcannotadequatelysupportthesessiondescribed.
The606(NotAcceptable)responseMAYcontainalistofreasonsina
Warningheaderfielddescribingwhythesessiondescribedcannotbe
supported.WarningreasoncodesarelistedinSection20.43.
AmessagebodycontainingadescriptionofmediacapabilitiesMAYbe
presentintheresponse,whichisformattedaccordingtotheAccept
headerfieldintheINVITE(orapplication/sdpifnotpresent),the
sameasamessagebodyina200(OK)responsetoanOPTIONSrequest.
Itishopedthatnegotiationwillnotfrequentlybeneeded,andwhen
anewuserisbeinginvitedtojoinanalreadyexistingconference,
negotiationmaynotbepossible.Itisuptotheinvitation
initiatortodecidewhetherornottoactona606(NotAcceptable)
response.
Thisstatusresponseisreturnedonlyiftheclientknowsthatno
otherendpointwillanswertherequest.
22UsageofHTTPAuthentication
SIPprovidesastateless,challengebasedmechanismfor
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,theBNFforauthscheme,authparam,
challenge,realm,realmvalue,andcredentialsisidentical(although
theusageof"Basic"asaschemeisnotpermitted).InSIP,aUAS
usesthe401(Unauthorized)responsetochallengetheidentityofa
UAC.Additionally,registrarsandredirectserversMAYmakeuseof
401(Unauthorized)responsesforauthentication,butproxiesMUST
NOT,andinsteadMAYusethe407(ProxyAuthenticationRequired)
response.TherequirementsforinclusionoftheProxyAuthenticate,
ProxyAuthorization,WWWAuthenticate,andAuthorizationinthe
variousmessagesareidenticaltothosedescribedinRFC2617[17].
SinceSIPdoesnothavetheconceptofacanonicalrootURL,the
notionofprotectionspacesisinterpreteddifferentlyinSIP.The
realmstringalonedefinestheprotectiondomain.Thisisachange
fromRFC2543,inwhichtheRequestURIandtherealmtogether
definedtheprotectiondomain.
Thispreviousdefinitionofprotectiondomaincausedsomeamount
ofconfusionsincetheRequestURIsentbytheUACandthe
RequestURIreceivedbythechallengingservermightbedifferent,
andindeedthefinalformoftheRequestURImightnotbeknownto
theUAC.Also,thepreviousdefinitiondependedonthepresence
ofaSIPURIintheRequestURIandseemedtoruleoutalternative
URIschemes(forexample,thetelURL).
Operatorsofuseragentsorproxyserversthatwillauthenticate
receivedrequestsMUSTadheretothefollowingguidelinesfor
creationofarealmstringfortheirserver:
oRealmstringsMUSTbegloballyunique.ItisRECOMMENDEDthat
arealmstringcontainahostnameordomainname,followingthe
recommendationinSection3.2.1ofRFC2617[17].
oRealmstringsSHOULDpresentahumanreadableidentifierthat
canberenderedtoauser.
Forexample:
Authorization:Digestrealm="biloxi.com",<...>
Generally,SIPauthenticationismeaningfulforaspecificrealm,a
protectiondomain.Thus,forDigestauthentication,eachsuch
protectiondomainhasitsownsetofusernamesandpasswords.Ifa
serverdoesnotrequireauthenticationforaparticularrequest,it
MAYacceptadefaultusername,"anonymous",whichhasnopassword
(passwordof"").Similarly,UACsrepresentingmanyusers,suchas
PSTNgateways,MAYhavetheirowndevicespecificusernameand
password,ratherthanaccountsforparticularusers,fortheirrealm.
WhileaservercanlegitimatelychallengemostSIPrequests,there
aretworequestsdefinedbythisdocumentthatrequirespecial
handlingforauthentication:ACKandCANCEL.
Underanauthenticationschemethatusesresponsestocarryvalues
usedtocomputenonces(suchasDigest),someproblemscomeupfor
anyrequeststhattakenoresponse,includingACK.Forthisreason,
anycredentialsintheINVITEthatwereacceptedbyaserverMUSTbe
acceptedbythatserverfortheACK.UACscreatinganACKmessage
willduplicatealloftheAuthorizationandProxyAuthorization
headerfieldvaluesthatappearedintheINVITEtowhichtheACK
corresponds.ServersMUSTNOTattempttochallengeanACK.
AlthoughtheCANCELmethoddoestakearesponse(a2xx),serversMUST
NOTattempttochallengeCANCELrequestssincetheserequestscannot
beresubmitted.Generally,aCANCELrequestSHOULDbeacceptedbya
serverifitcomesfromthesamehopthatsenttherequestbeing
canceled(providedthatsomesortoftransportornetworklayer
securityassociation,asdescribedinSection26.2.1,isinplace).
WhenaUACreceivesachallenge,itSHOULDrendertotheuserthe
contentsofthe"realm"parameterinthechallenge(whichappearsin
eitheraWWWAuthenticateheaderfieldorProxyAuthenticateheader
field)iftheUACdevicedoesnotalreadyknowofacredentialfor
therealminquestion.AserviceproviderthatpreconfiguresUAs
withcredentialsforitsrealmshouldbeawarethatuserswillnot
havetheopportunitytopresenttheirowncredentialsforthisrealm
whenchallengedatapreconfigureddevice.
Finally,notethatevenifaUACcanlocatecredentialsthatare
associatedwiththeproperrealm,thepotentialexiststhatthese
credentialsmaynolongerbevalidorthatthechallengingserver
willnotacceptthesecredentialsforwhateverreason(especially
when"anonymous"withnopasswordissubmitted).Inthisinstancea
servermayrepeatitschallenge,oritmayrespondwitha403
Forbidden.AUACMUSTNOTreattemptrequestswiththecredentials
thathavejustbeenrejected(thoughtherequestmayberetriedif
thenoncewasstale).
22.2UsertoUserAuthentication
WhenaUASreceivesarequestfromaUAC,theUASMAYauthenticate
theoriginatorbeforetherequestisprocessed.Ifnocredentials
(intheAuthorizationheaderfield)areprovidedintherequest,the
UAScanchallengetheoriginatortoprovidecredentialsbyrejecting
therequestwitha401(Unauthorized)statuscode.
TheWWWAuthenticateresponseheaderfieldMUSTbeincludedin401
(Unauthorized)responsemessages.Thefieldvalueconsistsofat
leastonechallengethatindicatestheauthenticationscheme(s)and
parametersapplicabletotherealm.
AnexampleoftheWWWAuthenticateheaderfieldina401challenge
is:
WWWAuthenticate:Digest
realm="biloxi.com",
qop="auth,authint",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
WhentheoriginatingUACreceivesthe401(Unauthorized),itSHOULD,
ifitisable,reoriginatetherequestwiththepropercredentials.
TheUACmayrequireinputfromtheoriginatinguserbefore
proceeding.Onceauthenticationcredentialshavebeensupplied
(eitherdirectlybytheuser,ordiscoveredinaninternalkeyring),
UAsSHOULDcachethecredentialsforagivenvalueoftheToheader
fieldand"realm"andattempttoreusethesevaluesonthenext
requestforthatdestination.UAsMAYcachecredentialsinanyway
theywouldlike.
Ifnocredentialsforarealmcanbelocated,UACsMAYattemptto
retrytherequestwithausernameof"anonymous"andnopassword(a
passwordof"").
Oncecredentialshavebeenlocated,anyUAthatwishesto
authenticateitselfwithaUASorregistrarusually,butnot
necessarily,afterreceivinga401(Unauthorized)responseMAYdo
sobyincludinganAuthorizationheaderfieldwiththerequest.The
Authorizationfieldvalueconsistsofcredentialscontainingthe
authenticationinformationoftheUAfortherealmoftheresource
beingrequestedaswellasparametersrequiredinsupportof
authenticationandreplayprotection.
AnexampleoftheAuthorizationheaderfieldis:
Authorization:Digestusername="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
WhenaUACresubmitsarequestwithitscredentialsafterreceivinga
401(Unauthorized)or407(ProxyAuthenticationRequired)response,
itMUSTincrementtheCSeqheaderfieldvalueasitwouldnormally
whensendinganupdatedrequest.
22.3ProxytoUserAuthentication
Similarly,whenaUACsendsarequesttoaproxyserver,theproxy
serverMAYauthenticatetheoriginatorbeforetherequestis
processed.Ifnocredentials(intheProxyAuthorizationheader
field)areprovidedintherequest,theproxycanchallengethe
originatortoprovidecredentialsbyrejectingtherequestwitha407
(ProxyAuthenticationRequired)statuscode.TheproxyMUSTpopulate
the407(ProxyAuthenticationRequired)messagewithaProxy
Authenticateheaderfieldvalueapplicabletotheproxyforthe
requestedresource.
TheuseofProxyAuthenticateandProxyAuthorizationparallelthat
describedin[17],withonedifference.ProxiesMUSTNOTaddvalues
totheProxyAuthorizationheaderfield.All407(Proxy
AuthenticationRequired)responsesMUSTbeforwardedupstreamtoward
theUACfollowingtheproceduresforanyotherresponse.Itisthe
UAC'sresponsibilitytoaddtheProxyAuthorizationheaderfield
valuecontainingcredentialsfortherealmoftheproxythathas
askedforauthentication.
IfaproxyweretoresubmitarequestaddingaProxyAuthorization
headerfieldvalue,itwouldneedtoincrementtheCSeqinthenew
request.However,thiswouldcausetheUACthatsubmittedthe
originalrequesttodiscardaresponsefromtheUAS,astheCSeq
valuewouldbedifferent.
WhentheoriginatingUACreceivesthe407(ProxyAuthentication
Required)itSHOULD,ifitisable,reoriginatetherequestwiththe
propercredentials.Itshouldfollowthesameproceduresforthe
displayofthe"realm"parameterthataregivenaboveforresponding
to401.
Ifnocredentialsforarealmcanbelocated,UACsMAYattemptto
retrytherequestwithausernameof"anonymous"andnopassword(a
passwordof"").
TheUACSHOULDalsocachethecredentialsusedinthereoriginated
request.
ThefollowingruleisRECOMMENDEDforproxycredentialcaching:
IfaUAreceivesaProxyAuthenticateheaderfieldvalueina401/407
responsetoarequestwithaparticularCallID,itshould
incorporatecredentialsforthatrealminallsubsequentrequests
thatcontainthesameCallID.ThesecredentialsMUSTNOTbecached
acrossdialogshowever,ifaUAisconfiguredwiththerealmofits
localoutboundproxy,whenoneexists,thentheUAMAYcache
credentialsforthatrealmacrossdialogs.Notethatthisdoesmean
afuturerequestinadialogcouldcontaincredentialsthatarenot
neededbyanyproxyalongtheRouteheaderpath.
AnyUAthatwishestoauthenticateitselftoaproxyserver
usually,butnotnecessarily,afterreceivinga407(Proxy
AuthenticationRequired)responseMAYdosobyincludingaProxy
Authorizationheaderfieldvaluewiththerequest.TheProxy
Authorizationrequestheaderfieldallowstheclienttoidentify
itself(oritsuser)toaproxythatrequiresauthentication.The
ProxyAuthorizationheaderfieldvalueconsistsofcredentials
containingtheauthenticationinformationoftheUAfortheproxy
and/orrealmoftheresourcebeingrequested.
AProxyAuthorizationheaderfieldvalueappliesonlytotheproxy
whoserealmisidentifiedinthe"realm"parameter(thisproxymay
previouslyhavedemandedauthenticationusingtheProxyAuthenticate
field).Whenmultipleproxiesareusedinachain,aProxy
AuthorizationheaderfieldvalueMUSTNOTbeconsumedbyanyproxy
whoserealmdoesnotmatchthe"realm"parameterspecifiedinthat
value.
Notethatifanauthenticationschemethatdoesnotsupportrealmsis
usedintheProxyAuthorizationheaderfield,aproxyserverMUST
attempttoparseallProxyAuthorizationheaderfieldvaluesto
determinewhetheroneofthemhaswhattheproxyserverconsidersto
bevalidcredentials.Becausethisispotentiallyverytime
consuminginlargenetworks,proxyserversSHOULDusean
authenticationschemethatsupportsrealmsintheProxyAuthorization
headerfield.
Ifarequestisforked(asdescribedinSection16.7),variousproxy
serversand/orUAsmaywishtochallengetheUAC.Inthiscase,the
forkingproxyserverisresponsibleforaggregatingthesechallenges
intoasingleresponse.EachWWWAuthenticateandProxyAuthenticate
valuereceivedinresponsestotheforkedrequestMUSTbeplacedinto
thesingleresponsethatissentbytheforkingproxytotheUAthe
orderingoftheseheaderfieldvaluesisnotsignificant.
Whenaproxyserverissuesachallengeinresponsetoarequest,
itwillnotproxytherequestuntiltheUAChasretriedthe
requestwithvalidcredentials.Aforkingproxymayforwarda
requestsimultaneouslytomultipleproxyserversthatrequire
authentication,eachofwhichinturnwillnotforwardtherequest
untiltheoriginatingUAChasauthenticateditselfintheir
respectiverealm.IftheUACdoesnotprovidecredentialsfor
eachchallenge,theproxyserversthatissuedthechallengeswill
notforwardrequeststotheUAwherethedestinationusermightbe
located,andtherefore,thevirtuesofforkingarelargelylost.
Whenresubmittingitsrequestinresponsetoa401(Unauthorized)or
407(ProxyAuthenticationRequired)thatcontainsmultiple
challenges,aUACMAYincludeanAuthorizationvalueforeachWWW
AuthenticatevalueandaProxyAuthorizationvalueforeachProxy
AuthenticatevalueforwhichtheUACwishestosupplyacredential.
Asnotedabove,multiplecredentialsinarequestSHOULDbe
differentiatedbythe"realm"parameter.
Itispossibleformultiplechallengesassociatedwiththesamerealm
toappearinthesame401(Unauthorized)or407(ProxyAuthentication
Required).Thiscanoccur,forexample,whenmultipleproxieswithin
thesameadministrativedomain,whichuseacommonrealm,arereached
byaforkingrequest.Whenitretriesarequest,aUACMAYtherefore
supplymultiplecredentialsinAuthorizationorProxyAuthorization
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=SIPURI/SIPSURI
2.TheBNFinRFC2617hasanerrorinthatthe'uri'parameter
oftheAuthorizationheaderfieldforHTTPDigest
authenticationisnotenclosedinquotationmarks.(The
exampleinSection3.5ofRFC2617iscorrect.)ForSIP,the
'uri'MUSTbeenclosedinquotationmarks.
3.TheBNFfordigesturivalueis:
digesturivalue=RequestURIasdefinedinSection25
4.TheexampleprocedureforchoosinganoncebasedonEtagdoes
notworkforSIP.
5.ThetextinRFC2617[17]regardingcacheoperationdoesnot
applytoSIP.
6.RFC2617[17]requiresthataservercheckthattheURIinthe
requestlineandtheURIincludedintheAuthorizationheader
fieldpointtothesameresource.InaSIPcontext,thesetwo
URIsmayrefertodifferentusers,duetoforwardingatsome
proxy.Therefore,inSIP,aserverMAYcheckthatthe
RequestURIintheAuthorizationheaderfieldvalue
correspondstoauserforwhomtheserveriswillingtoaccept
forwardedordirectrequests,butitisnotnecessarilya
failureifthetwofieldsarenotequivalent.
7.AsaclarificationtothecalculationoftheA2valuefor
messageintegrityassuranceintheDigestauthentication
scheme,implementersshouldassume,whentheentitybodyis
empty(thatis,whenSIPmessageshavenobody)thatthehash
oftheentitybodyresolvestotheMD5hashofanempty
string,or:
H(entitybody)=MD5("")=
"d41d8cd98f00b204e9800998ecf8427e"
8.RFC2617notesthatacnoncevalueMUSTNOTbesentinan
Authorization(andbyextensionProxyAuthorization)header
fieldifnoqopdirectivehasbeensent.Therefore,any
algorithmsthathaveadependencyonthecnonce(including
"MD5Sess")requirethattheqopdirectivebesent.Useof
the"qop"parameterisoptionalinRFC2617forthepurposes
ofbackwardscompatibilitywithRFC2069sinceRFC2543was
basedonRFC2069,the"qop"parametermustunfortunately
remainoptionalforclientsandserverstoreceive.However,
serversMUSTalwayssenda"qop"parameterinWWWAuthenticate
andProxyAuthenticateheaderfieldvalues.Ifaclient
receivesa"qop"parameterinachallengeheaderfield,it
MUSTsendthe"qop"parameterinanyresultingauthorization
headerfield.
RFC2543didnotallowusageoftheAuthenticationInfoheaderfield
(iteffectivelyusedRFC2069).However,wenowallowusageofthis
headerfield,sinceitprovidesintegritychecksoverthebodiesand
providesmutualauthentication.RFC2617[17]definesmechanismsfor
backwardscompatibilityusingtheqopattributeintherequest.
ThesemechanismsMUSTbeusedbyaservertodetermineiftheclient
supportsthenewmechanismsinRFC2617thatwerenotspecifiedin
RFC2069.
23S/MIME
SIPmessagescarryMIMEbodiesandtheMIMEstandardincludes
mechanismsforsecuringMIMEcontentstoensurebothintegrityand
confidentiality(includingthe'multipart/signed'and
'application/pkcs7mime'MIMEtypes,seeRFC1847[22],RFC2630[23]
andRFC2633[24]).Implementersshouldnote,however,thatthere
mayberarenetworkintermediaries(nottypicalproxyservers)that
relyonviewingormodifyingthebodiesofSIPmessages(especially
SDP),andthatsecureMIMEmaypreventthesesortsofintermediaries
fromfunctioning.
Thisappliesparticularlytocertaintypesoffirewalls.
ThePGPmechanismforencryptingtheheaderfieldsandbodiesof
SIPmessagesdescribedinRFC2543hasbeendeprecated.
23.1S/MIMECertificates
Thecertificatesthatareusedtoidentifyanenduserforthe
purposesofS/MIMEdifferfromthoseusedbyserversinoneimportant
respectratherthanassertingthattheidentityoftheholder
correspondstoaparticularhostname,thesecertificatesassertthat
theholderisidentifiedbyanenduseraddress.Thisaddressis
composedoftheconcatenationofthe"userinfo""@"and"domainname"
portionsofaSIPorSIPSURI(inotherwords,anemailaddressof
theform"bob@biloxi.com"),mostcommonlycorrespondingtoauser's
addressofrecord.
Thesecertificatesarealsoassociatedwithkeysthatareusedto
signorencryptbodiesofSIPmessages.Bodiesaresignedwiththe
privatekeyofthesender(whomayincludetheirpublickeywiththe
messageasappropriate),butbodiesareencryptedwiththepublickey
oftheintendedrecipient.Obviously,sendersmusthave
foreknowledgeofthepublickeyofrecipientsinordertoencrypt
messagebodies.PublickeyscanbestoredwithinaUAonavirtual
keyring.
EachuseragentthatsupportsS/MIMEMUSTcontainakeyring
specificallyforendusers'certificates.Thiskeyringshouldmap
betweenaddressesofrecordandcorrespondingcertificates.Over
time,usersSHOULDusethesamecertificatewhentheypopulatethe
originatingURIofsignaling(theFromheaderfield)withthesame
addressofrecord.
Anymechanismsdependingontheexistenceofendusercertificates
areseriouslylimitedinthatthereisvirtuallynoconsolidated
authoritytodaythatprovidescertificatesforenduserapplications.
However,usersSHOULDacquirecertificatesfromknownpublic
certificateauthorities.Asanalternative,usersMAYcreateself
signedcertificates.Theimplicationsofselfsignedcertificates
areexploredfurtherinSection26.4.2.Implementationsmayalsouse
preconfiguredcertificatesindeploymentsinwhichaprevioustrust
relationshipexistsbetweenallSIPentities.
Aboveandbeyondtheproblemofacquiringanendusercertificate,
therearefewwellknowncentralizeddirectoriesthatdistribute
endusercertificates.However,theholderofacertificateSHOULD
publishtheircertificateinanypublicdirectoriesasappropriate.
Similarly,UACsSHOULDsupportamechanismforimporting(manuallyor
automatically)certificatesdiscoveredinpublicdirectories
correspondingtothetargetURIsofSIPrequests.
23.2S/MIMEKeyExchange
SIPitselfcanalsobeusedasameanstodistributepublickeysin
thefollowingmanner.
WhenevertheCMSSignedDatamessageisusedinS/MIMEforSIP,it
MUSTcontainthecertificatebearingthepublickeynecessaryto
verifythesignature.
WhenaUACsendsarequestcontaininganS/MIMEbodythatinitiatesa
dialog,orsendsanonINVITErequestoutsidethecontextofa
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
oftherequest.Ifthecertificatecannotbeverified,becauseitis
selfsigned,orsignedbynoknownauthority,orifitisverifiable
butitssubjectdoesnotcorrespondtotheFromheaderfieldof
request,theUASMUSTnotifyitsuserofthestatusofthe
certificate(includingthesubjectofthecertificate,itssigner,
andanykeyfingerprintinformation)andrequestexplicitpermission
beforeproceeding.Ifthecertificatewassuccessfullyverifiedand
thesubjectofthecertificatecorrespondstotheFromheaderfield
oftheSIPrequest,oriftheuser(afternotification)explicitly
authorizestheuseofthecertificate,theUASSHOULDaddthis
certificatetoalocalkeyring,indexedbytheaddressofrecordof
theholderofthecertificate.
WhenaUASsendsaresponsecontaininganS/MIMEbodythatanswers
thefirstrequestinadialog,oraresponsetoanonINVITErequest
outsidethecontextofadialog,theUASSHOULDstructurethebodyas
anS/MIME'multipart/signed'CMSSignedDatabody.IfthedesiredCMS
serviceisEnvelopedData,theUASSHOULDsendtheEnvelopedData
messageencapsulatedwithinaSignedDatamessage.
WhenaUACreceivesaresponsecontaininganS/MIMECMSbodythat
includesacertificate,theUACSHOULDfirstvalidatethe
certificate,ifpossible,withanyappropriaterootcertificate.The
UACSHOULDalsodeterminethesubjectofthecertificateandcompare
thisvaluetotheTofieldoftheresponsealthoughthetwomayvery
wellbedifferent,andthisisnotnecessarilyindicativeofa
securitybreach.Ifthecertificatecannotbeverifiedbecauseitis
selfsigned,orsignedbynoknownauthority,theUACMUSTnotifyits
userofthestatusofthecertificate(includingthesubjectofthe
certificate,itssignator,andanykeyfingerprintinformation)and
requestexplicitpermissionbeforeproceeding.Ifthecertificate
wassuccessfullyverified,andthesubjectofthecertificate
correspondstotheToheaderfieldintheresponse,oriftheuser
(afternotification)explicitlyauthorizestheuseofthe
certificate,theUACSHOULDaddthiscertificatetoalocalkeyring,
indexedbytheaddressofrecordoftheholderofthecertificate.
IftheUAChadnottransmitteditsowncertificatetotheUASinany
previoustransaction,itSHOULDuseaCMSSignedDatabodyforits
nextrequestorresponse.
Onfutureoccasions,whentheUAreceivesrequestsorresponsesthat
containaFromheaderfieldcorrespondingtoavalueinitskeyring,
theUASHOULDcomparethecertificateofferedinthesemessageswith
theexistingcertificateinitskeyring.Ifthereisadiscrepancy,
theUAMUSTnotifyitsuserofachangeofthecertificate
(preferablyintermsthatindicatethatthisisapotentialsecurity
breach)andacquiretheuser'spermissionbeforecontinuingto
processthesignaling.Iftheuserauthorizesthiscertificate,it
SHOULDbeaddedtothekeyringalongsideanypreviousvalue(s)for
thisaddressofrecord.
Notewellhowever,thatthiskeyexchangemechanismdoesnot
guaranteethesecureexchangeofkeyswhenselfsignedcertificates,
orcertificatessignedbyanobscureauthority,areuseditis
vulnerabletowellknownattacks.Intheopinionoftheauthors,
however,thesecurityitprovidesisproverbiallybetterthan
nothingitisinfactcomparabletothewidelyusedSSHapplication.
TheselimitationsareexploredingreaterdetailinSection26.4.2.
IfaUAreceivesanS/MIMEbodythathasbeenencryptedwithapublic
keyunknowntotherecipient,itMUSTrejecttherequestwitha493
(Undecipherable)response.ThisresponseSHOULDcontainavalid
certificatefortherespondent(corresponding,ifpossible,toany
addressofrecordgivenintheToheaderfieldoftherejected
request)withinaMIMEbodywitha'certsonly'"smimetype"
parameter.
A493(Undecipherable)sentwithoutanycertificateindicatesthat
therespondentcannotorwillnotutilizeS/MIMEencryptedmessages,
thoughtheymaystillsupportS/MIMEsignatures.
NotethatauseragentthatreceivesarequestcontaininganS/MIME
bodythatisnotoptional(withaContentDispositionheader
"handling"parameterof"required")MUSTrejecttherequestwitha
415UnsupportedMediaTyperesponseiftheMIMEtypeisnot
understood.AuseragentthatreceivessucharesponsewhenS/MIME
issentSHOULDnotifyitsuserthattheremotedevicedoesnot
supportS/MIME,anditMAYsubsequentlyresendtherequestwithout
S/MIME,ifappropriatehowever,this415responsemayconstitutea
downgradeattack.
IfauseragentsendsanS/MIMEbodyinarequest,butreceivesa
responsethatcontainsaMIMEbodythatisnotsecured,theUAC
SHOULDnotifyitsuserthatthesessioncouldnotbesecured.
However,ifauseragentthatsupportsS/MIMEreceivesarequestwith
anunsecuredbody,itSHOULDNOTrespondwithasecuredbody,butif
itexpectsS/MIMEfromthesender(forexample,becausethesender's
Fromheaderfieldvaluecorrespondstoanidentityonitskeychain),
theUASSHOULDnotifyitsuserthatthesessioncouldnotbesecured.
Anumberofconditionsthatariseintheprevioustextcallforthe
notificationoftheuserwhenananomalouscertificatemanagement
eventoccurs.Usersmightwellaskwhattheyshoulddounderthese
circumstances.Firstandforemost,anunexpectedchangeina
certificate,oranabsenceofsecuritywhensecurityisexpected,are
causesforcautionbutnotnecessarilyindicationsthatanattackis
inprogress.Usersmightabortanyconnectionattemptorrefusea
connectionrequesttheyhavereceivedintelephonyparlance,they
couldhangupandcallback.Usersmaywishtofindanalternate
meanstocontacttheotherpartyandconfirmthattheirkeyhas
legitimatelychanged.Notethatusersaresometimescompelledto
changetheircertificates,forexamplewhentheysuspectthatthe
secrecyoftheirprivatekeyhasbeencompromised.Whentheir
privatekeyisnolongerprivate,usersmustlegitimatelygeneratea
newkeyandreestablishtrustwithanyusersthatheldtheirold
key.
Finally,ifduringthecourseofadialogaUAreceivesacertificate
inaCMSSignedDatamessagethatdoesnotcorrespondwiththe
certificatespreviouslyexchangedduringadialog,theUAMUSTnotify
itsuserofthechange,preferablyintermsthatindicatethatthis
isapotentialsecuritybreach.
23.3SecuringMIMEbodies
TherearetwotypesofsecureMIMEbodiesthatareofinterestto
SIP:useofthesebodiesshouldfollowtheS/MIMEspecification[24]
withafewvariations.
o"multipart/signed"MUSTbeusedonlywithCMSdetached
signatures.
ThisallowsbackwardscompatibilitywithnonS/MIME
compliantrecipients.
oS/MIMEbodiesSHOULDhaveaContentDispositionheaderfield,
andthevalueofthe"handling"parameterSHOULDbe"required."
oIfaUAChasnocertificateonitskeyringassociatedwiththe
addressofrecordtowhichitwantstosendarequest,it
cannotsendanencrypted"application/pkcs7mime"MIMEmessage.
UACsMAYsendaninitialrequestsuchasanOPTIONSmessage
withaCMSdetachedsignatureinordertosolicitthe
certificateoftheremoteside(thesignatureSHOULDbeovera
"message/sip"bodyofthetypedescribedinSection23.4).
NotethatfuturestandardizationworkonS/MIMEmaydefine
noncertificatebasedkeys.
oSendersofS/MIMEbodiesSHOULDusethe"SMIMECapabilities"
(seeSection2.5.2of[24])attributetoexpresstheir
capabilitiesandpreferencesforfurthercommunications.Note
especiallythatsendersMAYusethe"preferSignedData"
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:
Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bKnashds8
CSeq:314159INVITE
MaxForwards:70
ContentType:application/pkcs7mimesmimetype=envelopeddata
name=smime.p7m
ContentDisposition:attachmentfilename=smime.p7m
handling=required
*******************************************************
*ContentType:application/sdp*
**
*v=0*
*o=alice536557652353687637INIP4pc33.atlanta.com*
*s=*
*t=00*
*c=INIP4pc33.atlanta.com*
*m=audio3456RTP/AVP01399*
*a=rtpmap:0PCMU/8000*
*******************************************************
23.4SIPHeaderPrivacyandIntegrityusingS/MIME:TunnelingSIP
Asameansofprovidingsomedegreeofendtoendauthentication,
integrityorconfidentialityforSIPheaderfields,S/MIMEcan
encapsulateentireSIPmessageswithinMIMEbodiesoftype
"message/sip"andthenapplyMIMEsecuritytothesebodiesinthe
samemannerastypicalSIPbodies.TheseencapsulatedSIPrequests
andresponsesdonotconstituteaseparatedialogortransaction,
theyareacopyofthe"outer"messagethatisusedtoverify
integrityortosupplyadditionalinformation.
IfaUASreceivesarequestthatcontainsatunneled"message/sip"
S/MIMEbody,itSHOULDincludeatunneled"message/sip"bodyinthe
responsewiththesamesmimetype.
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:
RequestURI,Via,RecordRoute,Route,MaxForwards,andProxy
Authorization.Iftheseheaderfieldsarenotintactendtoend,
implementationsSHOULDNOTconsiderthisabreachofsecurity.
Changestoanyotherheaderfieldsdefinedinthisdocument
constituteanintegrityviolationusersMUSTbenotifiedofa
discrepancy.
23.4.1.2Confidentiality
Whenmessagesareencrypted,headerfieldsmaybeincludedinthe
encryptedbodythatarenotpresentinthe"outer"message.
Someheaderfieldsmustalwayshaveaplaintextversionbecausethey
arerequiredheaderfieldsinrequestsandresponsestheseinclude:
To,From,CallID,CSeq,Contact.Whileitisprobablynotusefulto
provideanencryptedalternativefortheCallID,CSeq,orContact,
providinganalternativetotheinformationinthe"outer"ToorFrom
ispermitted.Notethatthevaluesinanencryptedbodyarenotused
forthepurposesofidentifyingtransactionsordialogstheyare
merelyinformational.IftheFromheaderfieldinanencryptedbody
differsfromthevalueinthe"outer"message,thevaluewithinthe
encryptedbodySHOULDbedisplayedtotheuser,butMUSTNOTbeused
inthe"outer"headerfieldsofanyfuturemessages.
Primarily,auseragentwillwanttoencryptheaderfieldsthathave
anendtoendsemantic,including:Subject,ReplyTo,Organization,
Accept,AcceptEncoding,AcceptLanguage,AlertInfo,ErrorInfo,
AuthenticationInfo,Expires,InReplyTo,Require,Supported,
Unsupported,RetryAfter,UserAgent,Server,andWarning.Ifanyof
theseheaderfieldsarepresentinanencryptedbody,theyshouldbe
usedinsteadofany"outer"headerfields,whetherthisentails
displayingtheheaderfieldvaluestousersorsettinginternal
statesintheUA.TheySHOULDNOThoweverbeusedinthe"outer"
headersofanyfuturemessages.
Ifpresent,theDateheaderfieldMUSTalwaysbethesameinthe
"inner"and"outer"headers.
SinceMIMEbodiesareattachedtothe"inner"message,
implementationswillusuallyencryptMIMEspecificheaderfields,
including:MIMEVersion,ContentType,ContentLength,Content
Language,ContentEncodingandContentDisposition.The"outer"
messagewillhavetheproperMIMEheaderfieldsforS/MIMEbodies.
Theseheaderfields(andanyMIMEbodiestheypreface)shouldbe
treatedasnormalMIMEheaderfieldsandbodiesreceivedinaSIP
message.
Itisnotparticularlyusefultoencryptthefollowingheaderfields:
MinExpires,Timestamp,Authorization,Priority,andWWW
Authenticate.Thiscategoryalsoincludesthoseheaderfieldsthat
canbechangedbyproxyservers(describedintheprecedingsection).
UAsSHOULDneverincludetheseinan"inner"messageiftheyarenot
includedinthe"outer"message.UAsthatreceiveanyofthese
headerfieldsinanencryptedbodySHOULDignoretheencrypted
values.
NotethatextensionstoSIPmaydefineadditionalheaderfieldsthe
authorsoftheseextensionsshoulddescribetheintegrityand
confidentialitypropertiesofsuchheaderfields.IfaSIPUA
encountersanunknownheaderfieldwithanintegrityviolation,it
MUSTignoretheheaderfield.
23.4.2TunnelingIntegrityandAuthentication
TunnelingSIPmessageswithinS/MIMEbodiescanprovideintegrityfor
SIPheaderfieldsiftheheaderfieldsthatthesenderwishesto
securearereplicatedina"message/sip"MIMEbodysignedwithaCMS
detachedsignature.
Providedthatthe"message/sip"bodycontainsatleastthe
fundamentaldialogidentifiers(To,From,CallID,CSeq),thena
signedMIMEbodycanprovidelimitedauthentication.Atthevery
least,ifthecertificateusedtosignthebodyisunknowntothe
recipientandcannotbeverified,thesignaturecanbeusedto
ascertainthatalaterrequestinadialogwastransmittedbythe
samecertificateholderthatinitiatedthedialog.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.
Thefollowingisanexampleoftheuseofatunneled"message/sip"
body:
CSeq:314159INVITE
MaxForwards:70
Date:Thu,21Feb200213:02:03GMT
ContentType:multipart/signed
protocol="application/pkcs7signature"
micalg=sha1boundary=boundary42
ContentLength:568
boundary42
ContentType:message/sip
To:Bob<bob@biloxi.com>
From:Alice<alice@atlanta.com>tag=1928301774
CSeq:314159INVITE
MaxForwards:70
ContentLength:147
v=0
o=UserA28908445262890844526INIP4here.com
s=SessionSDP
c=INIP4pc33.atlanta.com
t=00
m=audio49172RTP/AVP0
a=rtpmap:0PCMU/8000
boundary42
ContentType:application/pkcs7signaturename=smime.p7s
ContentTransferEncoding:base64
ContentDisposition:attachmentfilename=smime.p7s
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
boundary42
23.4.3TunnelingEncryption
Itmayalsobedesirabletousethismechanismtoencrypta
"message/sip"MIMEbodywithinaCMSEnvelopedDatamessageS/MIME
body,butinpractice,mostheaderfieldsareofatleastsomeuseto
thenetworkthegeneraluseofencryptionwithS/MIMEistosecure
messagebodieslikeSDPratherthanmessageheaders.Some
informationalheaderfields,suchastheSubjectorOrganization
couldperhapswarrantendtoendsecurity.Headersdefinedbyfuture
SIPapplicationsmightalsorequireobfuscation.
Anotherpossibleapplicationofencryptingheaderfieldsisselective
anonymity.ArequestcouldbeconstructedwithaFromheaderfield
thatcontainsnopersonalinformation(forexample,
sip:anonymous@anonymizer.invalid).However,asecondFromheader
fieldcontainingthegenuineaddressofrecordoftheoriginator
couldbeencryptedwithina"message/sip"MIMEbodywhereitwill
onlybevisibletotheendpointsofadialog.
Notethatifthismechanismisusedforanonymity,theFromheader
fieldwillnolongerbeusablebytherecipientofamessageasan
indextotheircertificatekeychainforretrievingtheproper
S/MIMEkeytoassociatedwiththesender.Themessagemustfirst
bedecrypted,andthe"inner"FromheaderfieldMUSTbeusedasan
index.
Inordertoprovideendtoendintegrity,encrypted"message/sip"
MIMEbodiesSHOULDbesignedbythesender.Thiscreatesa
"multipart/signed"MIMEbodythatcontainsanencryptedbodyanda
signature,bothoftype"application/pkcs7mime".
Inthefollowingexample,ofanencryptedandsignedmessage,the
textboxedinasterisks("*")isencrypted:
From:Anonymous<sip:anonymous@atlanta.com>tag=1928301774
CSeq:314159INVITE
MaxForwards:70
Contact:<sip:pc33.atlanta.com>
ContentType:multipart/signed
protocol="application/pkcs7signature"
micalg=sha1boundary=boundary42
ContentLength:568
boundary42
ContentType:application/pkcs7mimesmimetype=envelopeddata
name=smime.p7m
ContentDisposition:attachmentfilename=smime.p7m
handling=required
ContentLength:231
***********************************************************
*ContentType:message/sip*
**
*INVITEsip:bob@biloxi.comSIP/2.0*
*Via:SIP/2.0/UDPpc33.atlanta.combranch=z9hG4bKnashds8*
*To:Bob<bob@biloxi.com>*
*From:Alice<alice@atlanta.com>tag=1928301774*
*CallID:a84b4c76e66710*
*CSeq:314159INVITE*
*MaxForwards:70*
*Date:Thu,21Feb200213:02:03GMT*
*Contact:<sip:alice@pc33.atlanta.com>*
**
*ContentType:application/sdp*
**
*v=0*
*o=alice536557652353687637INIP4pc33.atlanta.com*
*s=SessionSDP*
*t=00*
*c=INIP4pc33.atlanta.com*
*m=audio3456RTP/AVP01399*
*a=rtpmap:0PCMU/8000*
***********************************************************
boundary42
ContentType:application/pkcs7signaturename=smime.p7s
ContentDisposition:attachmentfilename=smime.p7s
handling=required
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
boundary42
24Examples
Inthefollowingexamples,weoftenomitthemessagebodyandthe
correspondingContentLengthandContentTypeheaderfieldsfor
brevity.
24.1Registration
Bobregistersonstartup.ThemessageflowisshowninFigure9.
Notethattheauthenticationusuallyrequiredforregistrationisnot
shownforsimplicity.
biloxi.comBob's
registrarsoftphone
||
|REGISTERF1|
|<|
|200OKF2|
|>|
Figure9:SIPRegistrationExample
F1REGISTERBob>Registrar
REGISTERsip:registrar.biloxi.comSIP/2.0
Via:SIP/2.0/UDPbobspc.biloxi.com:5060branch=z9hG4bKnashds7
MaxForwards:70
From:Bob<sip:bob@biloxi.com>tag=456248
CallID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Expires:7200
ContentLength:0
Theregistrationexpiresaftertwohours.Theregistrarresponds
witha200OK:
F2200OKRegistrar>Bob
SIP/2.0200OK
Via:SIP/2.0/UDPbobspc.biloxi.com:5060branch=z9hG4bKnashds7
received=192.0.2.4
To:Bob<sip:bob@biloxi.com>tag=2493k59kd
From:Bob<sip:bob@biloxi.com>tag=456248
CallID:843817637684230@998sdasdh09
CSeq:1826REGISTER
Expires:7200
ContentLength:0
24.2SessionSetup
Thisexamplecontainsthefulldetailsoftheexamplesessionsetup
inSection4.ThemessageflowisshowninFigure1.Notethat
theseflowsshowtheminimumrequiredsetofheaderfieldssome
otherheaderfieldssuchasAllowandSupportedwouldnormallybe
present.
F1INVITEAlice>atlanta.comproxy
MaxForwards:70
CSeq:314159INVITE
ContentLength:142
F2100Tryingatlanta.comproxy>Alice
SIP/2.0100Trying
received=192.0.2.1
CSeq:314159INVITE
ContentLength:0
F3INVITEatlanta.comproxy>biloxi.comproxy
Via:SIP/2.0/UDPbigbox3.site3.atlanta.combranch=z9hG4bK77ef4c2312983.1
received=192.0.2.1
MaxForwards:69
CSeq:314159INVITE
ContentLength:142
F4100Tryingbiloxi.comproxy>atlanta.comproxy
SIP/2.0100Trying
received=192.0.2.2
received=192.0.2.1
CSeq:314159INVITE
ContentLength:0
F5INVITEbiloxi.comproxy>Bob
INVITEsip:bob@192.0.2.4SIP/2.0
Via:SIP/2.0/UDPserver10.biloxi.combranch=z9hG4bK4b43c2ff8.1
received=192.0.2.2
received=192.0.2.1
MaxForwards:68
CSeq:314159INVITE
ContentLength:142
F6180RingingBob>biloxi.comproxy
SIP/2.0180Ringing
received=192.0.2.3
received=192.0.2.2
received=192.0.2.1
CSeq:314159INVITE
ContentLength:0
F7180Ringingbiloxi.comproxy>atlanta.comproxy
SIP/2.0180Ringing
received=192.0.2.2
received=192.0.2.1
CSeq:314159INVITE
ContentLength:0
F8180Ringingatlanta.comproxy>Alice
SIP/2.0180Ringing
received=192.0.2.1
CSeq:314159INVITE
ContentLength:0
F9200OKBob>biloxi.comproxy
SIP/2.0200OK
received=192.0.2.3
received=192.0.2.2
received=192.0.2.1
CSeq:314159INVITE
ContentLength:131
(Bob'sSDPnotshown)
F10200OKbiloxi.comproxy>atlanta.comproxy
SIP/2.0200OK
received=192.0.2.2
received=192.0.2.1
CSeq:314159INVITE
ContentLength:131
(Bob'sSDPnotshown)
F11200OKatlanta.comproxy>Alice
SIP/2.0200OK
received=192.0.2.1
CSeq:314159INVITE
ContentLength:131
(Bob'sSDPnotshown)
F12ACKAlice>Bob
ACKsip:bob@192.0.2.4SIP/2.0
MaxForwards:70
CSeq:314159ACK
ContentLength:0
ThemediasessionbetweenAliceandBobisnowestablished.
Bobhangsupfirst.NotethatBob'sSIPphonemaintainsitsownCSeq
numberingspace,which,inthisexample,beginswith231.SinceBob
ismakingtherequest,theToandFromURIsandtagshavebeen
swapped.
F13BYEBob>Alice
BYEsip:alice@pc33.atlanta.comSIP/2.0
Via:SIP/2.0/UDP192.0.2.4branch=z9hG4bKnashds10
MaxForwards:70
From:Bob<sip:bob@biloxi.com>tag=a6c85cf
To:Alice<sip:alice@atlanta.com>tag=1928301774
CSeq:231BYE
ContentLength:0
F14200OKAlice>Bob
SIP/2.0200OK
Via:SIP/2.0/UDP192.0.2.4branch=z9hG4bKnashds10
From:Bob<sip:bob@biloxi.com>tag=a6c85cf
To:Alice<sip:alice@atlanta.com>tag=1928301774
CSeq:231BYE
ContentLength:0
TheSIPCallFlowsdocument[40]containsfurtherexamplesofSIP
messages.
25AugmentedBNFfortheSIPProtocol
Allofthemechanismsspecifiedinthisdocumentaredescribedin
bothproseandanaugmentedBackusNaurForm(BNF)definedinRFC
2234[10].Section6.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.TheUSASCIIcodedcharacterset
isdefinedbyANSIX3.41986.
alphanum=ALPHA/DIGIT
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*WSPlinearwhitespace
SWS=[LWS]sepwhitespace
Toseparatetheheadernamefromtherestofvalue,acolonisused,
which,bytheaboverule,allowswhitespacebefore,butnoline
break,andwhitespaceafter,includingalinebreak.TheHCOLON
definesthisconstruct.
HCOLON=*(SP/HTAB)":"SWS
TheTEXTUTF8ruleisonlyusedfordescriptivefieldcontentsand
valuesthatarenotintendedtobeinterpretedbythemessageparser.
Wordsof*TEXTUTF8containcharactersfromtheUTF8charset(RFC
2279[7]).TheTEXTUTF8TRIMruleisusedfordescriptivefield
contentsthatarentquotedstrings,whereleadingandtrailingLWS
isnotmeaningful.Inthisregard,SIPdiffersfromHTTP,whichuses
theISO88591characterset.
TEXTUTF8TRIM=1*TEXTUTF8char*(*LWSTEXTUTF8char)
TEXTUTF8char=%x217E/UTF8NONASCII
UTF8NONASCII=%xC0DF1UTF8CONT
/%xE0EF2UTF8CONT
/%xF0F73UTF8CONT
/%xF8Fb4UTF8CONT
/%xFCFD5UTF8CONT
UTF8CONT=%x80BF
ACRLFisallowedinthedefinitionofTEXTUTF8TRIMonlyaspartof
aheaderfieldcontinuation.ItisexpectedthatthefoldingLWS
willbereplacedwithasingleSPbeforeinterpretationoftheTEXT
UTF8TRIMvalue.
Hexadecimalnumericcharactersareusedinseveralprotocolelements.
Someelements(authentication)forcehexalphastobelowercase.
LHEX=DIGIT/%x6166lowercaseaf
ManySIPheaderfieldvaluesconsistofwordsseparatedbyLWSor
specialcharacters.Unlessotherwisestated,tokensarecase
insensitive.ThesespecialcharactersMUSTbeinaquotedstringto
beusedwithinaparametervalue.Thewordconstructisusedin
CallIDtoallowmostseparatorstobeused.
token=1*(alphanum/""/"."/"!"/"%"/"*"
/"_"/"+"/"`"/"'"/"~")
separators="("/")"/"<"/">"/"@"/
","/""/":"/"\"/DQUOTE/
"/"/"["/"]"/"?"/"="/
"{"/"}"/SP/HTAB
word=1*(alphanum/""/"."/"!"/"%"/"*"/
"_"/"+"/"`"/"'"/"~"/
"("/")"/"<"/">"/
":"/"\"/DQUOTE/
"/"/"["/"]"/"?"/
"{"/"}")
Whentokensareusedorseparatorsareusedbetweenelements,
whitespaceisoftenallowedbeforeorafterthesecharacters:
STAR=SWS"*"SWSasterisk
SLASH=SWS"/"SWSslash
EQUAL=SWS"="SWSequal
LPAREN=SWS"("SWSleftparenthesis
RPAREN=SWS")"SWSrightparenthesis
RAQUOT=">"SWSrightanglequote
LAQUOT=SWS"<"leftanglequote
COMMA=SWS","SWScomma
SEMI=SWS""SWSsemicolon
COLON=SWS":"SWScolon
LDQUOT=SWSDQUOTEopendoublequotationmark
RDQUOT=DQUOTESWSclosedoublequotationmark
CommentscanbeincludedinsomeSIPheaderfieldsbysurroundingthe
commenttextwithparentheses.Commentsareonlyallowedinfields
containing"comment"aspartoftheirfieldvaluedefinition.Inall
otherfields,parenthesesareconsideredpartofthefieldvalue.
comment=LPAREN*(ctext/quotedpair/comment)RPAREN
ctext=%x2127/%x2A5B/%x5D7E/UTF8NONASCII
/LWS
ctextincludesallcharsexceptleftandrightparensandbackslash.
Astringoftextisparsedasasinglewordifitisquotedusing
doublequotemarks.Inquotedstrings,quotationmarks(")and
backslashes(\)needtobeescaped.
quotedstring=SWSDQUOTE*(qdtext/quotedpair)DQUOTE
qdtext=LWS/%x21/%x235B/%x5D7E
/UTF8NONASCII
Thebackslashcharacter("\")MAYbeusedasasinglecharacter
quotingmechanismonlywithinquotedstringandcommentconstructs.
UnlikeHTTP/1.1,thecharactersCRandLFcannotbeescapedbythis
mechanismtoavoidconflictwithlinefoldingandheaderseparation.
quotedpair="\"(%x0009/%x0B0C
/%x0E7F)
SIPURI="sip:"[userinfo]hostport
uriparameters[headers]
SIPSURI="sips:"[userinfo]hostport
uriparameters[headers]
userinfo=(user/telephonesubscriber)[":"password]"@"
user=1*(unreserved/escaped/userunreserved)
userunreserved="&"/"="/"+"/"$"/","/""/"?"/"/"
password=*(unreserved/escaped/
"&"/"="/"+"/"$"/",")
hostport=host[":"port]
host=hostname/IPv4address/IPv6reference
hostname=*(domainlabel".")toplabel["."]
domainlabel=alphanum
/alphanum*(alphanum/"")alphanum
toplabel=ALPHA/ALPHA*(alphanum/"")alphanum
IPv4address=1*3DIGIT"."1*3DIGIT"."1*3DIGIT"."1*3DIGIT
IPv6reference="["IPv6address"]"
IPv6address=hexpart[":"IPv4address]
hexpart=hexseq/hexseq"::"[hexseq]/"::"[hexseq]
hexseq=hex4*(":"hex4)
hex4=1*4HEXDIG
port=1*DIGIT
TheBNFfortelephonesubscribercanbefoundinRFC2806[9].Note,
however,thatanycharactersallowedtherethatarenotallowedin
theuserpartoftheSIPURIMUSTbeescaped.
uriparameters=*(""uriparameter)
uriparameter=transportparam/userparam/methodparam
/ttlparam/maddrparam/lrparam/otherparam
transportparam="transport="
("udp"/"tcp"/"sctp"/"tls"
/othertransport)
othertransport=token
userparam="user="("phone"/"ip"/otheruser)
otheruser=token
methodparam="method="Method
ttlparam="ttl="ttl
maddrparam="maddr="host
lrparam="lr"
otherparam=pname["="pvalue]
pname=1*paramchar
pvalue=1*paramchar
paramchar=paramunreserved/unreserved/escaped
paramunreserved="["/"]"/"/"/":"/"&"/"+"/"$"
headers="?"header*("&"header)
header=hname"="hvalue
hname=1*(hnvunreserved/unreserved/escaped)
hvalue=*(hnvunreserved/unreserved/escaped)
hnvunreserved="["/"]"/"/"/"?"/":"/"+"/"$"
SIPmessage=Request/Response
Request=RequestLine
*(messageheader)
CRLF
[messagebody]
RequestLine=MethodSPRequestURISPSIPVersionCRLF
RequestURI=SIPURI/SIPSURI/absoluteURI
absoluteURI=scheme":"(hierpart/opaquepart)
hierpart=(netpath/abspath)["?"query]
netpath="//"authority[abspath]
abspath="/"pathsegments
opaquepart=uricnoslash*uric
uric=reserved/unreserved/escaped
uricnoslash=unreserved/escaped/""/"?"/":"/"@"
/"&"/"="/"+"/"$"/","
pathsegments=segment*("/"segment)
segment=*pchar*(""param)
param=*pchar
pchar=unreserved/escaped/
":"/"@"/"&"/"="/"+"/"$"/","
scheme=ALPHA*(ALPHA/DIGIT/"+"/""/".")
authority=srvr/regname
srvr=[[userinfo"@"]hostport]
regname=1*(unreserved/escaped/"$"/","
/""/":"/"@"/"&"/"="/"+")
query=*uric
SIPVersion="SIP""/"1*DIGIT"."1*DIGIT
messageheader=(Accept
/AcceptEncoding
/AcceptLanguage
/AlertInfo
/Allow
/AuthenticationInfo
/Authorization
/CallID
/CallInfo
/Contact
/ContentDisposition
/ContentEncoding
/ContentLanguage
/ContentLength
/ContentType
/CSeq
/Date
/ErrorInfo
/Expires
/From
/InReplyTo
/MaxForwards
/MIMEVersion
/MinExpires
/Organization
/Priority
/ProxyAuthenticate
/ProxyAuthorization
/ProxyRequire
/RecordRoute
/ReplyTo
/Require
/RetryAfter
/Route
/Server
/Subject
/Supported
/Timestamp
/To
/Unsupported
/UserAgent
/Via
/Warning
/WWWAuthenticate
/extensionheader)CRLF
INVITEm=%x49.4E.56.49.54.45INVITEincaps
ACKm=%x41.43.4BACKincaps
OPTIONSm=%x4F.50.54.49.4F.4E.53OPTIONSincaps
BYEm=%x42.59.45BYEincaps
CANCELm=%x43.41.4E.43.45.4CCANCELincaps
REGISTERm=%x52.45.47.49.53.54.45.52REGISTERincaps
Method=INVITEm/ACKm/OPTIONSm/BYEm
/CANCELm/REGISTERm
/extensionmethod
extensionmethod=token
Response=StatusLine
*(messageheader)
CRLF
[messagebody]
StatusLine=SIPVersionSPStatusCodeSPReasonPhraseCRLF
StatusCode=Informational
/Redirection
/Success
/ClientError
/ServerError
/GlobalFailure
/extensioncode
extensioncode=3DIGIT
ReasonPhrase=*(reserved/unreserved/escaped
/UTF8NONASCII/UTF8CONT/SP/HTAB)
Informational="100"Trying
/"180"Ringing
/"181"CallIsBeingForwarded
/"182"Queued
/"183"SessionProgress
Success="200"OK
Redirection="300"MultipleChoices
/"301"MovedPermanently
/"302"MovedTemporarily
/"305"UseProxy
/"380"AlternativeService
ClientError="400"BadRequest
/"401"Unauthorized
/"402"PaymentRequired
/"403"Forbidden
/"404"NotFound
/"405"MethodNotAllowed
/"406"NotAcceptable
/"407"ProxyAuthenticationRequired
/"408"RequestTimeout
/"410"Gone
/"413"RequestEntityTooLarge
/"414"RequestURITooLarge
/"415"UnsupportedMediaType
/"416"UnsupportedURIScheme
/"420"BadExtension
/"421"ExtensionRequired
/"423"IntervalTooBrief
/"480"Temporarilynotavailable
/"481"CallLeg/TransactionDoesNotExist
/"482"LoopDetected
/"483"TooManyHops
/"484"AddressIncomplete
/"485"Ambiguous
/"486"BusyHere
/"487"RequestTerminated
/"488"NotAcceptableHere
/"491"RequestPending
/"493"Undecipherable
ServerError="500"InternalServerError
/"501"NotImplemented
/"502"BadGateway
/"503"ServiceUnavailable
/"504"ServerTimeout
/"505"SIPVersionnotsupported
/"513"MessageTooLarge
GlobalFailure="600"BusyEverywhere
/"603"Decline
/"604"Doesnotexistanywhere
/"606"NotAcceptable
Accept="Accept"HCOLON
[acceptrange*(COMMAacceptrange)]
acceptrange=mediarange*(SEMIacceptparam)
mediarange=("*/*"
/(mtypeSLASH"*")
/(mtypeSLASHmsubtype)
)*(SEMImparameter)
acceptparam=("q"EQUALqvalue)/genericparam
qvalue=("0"["."0*3DIGIT])
/("1"["."0*3("0")])
genericparam=token[EQUALgenvalue]
genvalue=token/host/quotedstring
AcceptEncoding="AcceptEncoding"HCOLON
[encoding*(COMMAencoding)]
encoding=codings*(SEMIacceptparam)
codings=contentcoding/"*"
contentcoding=token
AcceptLanguage="AcceptLanguage"HCOLON
[language*(COMMAlanguage)]
language=languagerange*(SEMIacceptparam)
languagerange=((1*8ALPHA*(""1*8ALPHA))/"*")
AlertInfo="AlertInfo"HCOLONalertparam*(COMMAalertparam)
alertparam=LAQUOTabsoluteURIRAQUOT*(SEMIgenericparam)
Allow="Allow"HCOLON[Method*(COMMAMethod)]
Authorization="Authorization"HCOLONcredentials
credentials=("Digest"LWSdigestresponse)
/otherresponse
digestresponse=digresp*(COMMAdigresp)
digresp=username/realm/nonce/digesturi
/dresponse/algorithm/cnonce
/opaque/messageqop
/noncecount/authparam
username="username"EQUALusernamevalue
usernamevalue=quotedstring
digesturi="uri"EQUALLDQUOTdigesturivalueRDQUOT
digesturivalue=rquesturiEqualtorequesturiasspecified
byHTTP/1.1
messageqop="qop"EQUALqopvalue
cnonce="cnonce"EQUALcnoncevalue
cnoncevalue=noncevalue
noncecount="nc"EQUALncvalue
ncvalue=8LHEX
dresponse="response"EQUALrequestdigest
requestdigest=LDQUOT32LHEXRDQUOT
authparam=authparamnameEQUAL
(token/quotedstring)
authparamname=token
otherresponse=authschemeLWSauthparam
*(COMMAauthparam)
authscheme=token
AuthenticationInfo="AuthenticationInfo"HCOLONainfo
*(COMMAainfo)
ainfo=nextnonce/messageqop
/responseauth/cnonce
/noncecount
nextnonce="nextnonce"EQUALnoncevalue
responseauth="rspauth"EQUALresponsedigest
responsedigest=LDQUOT*LHEXRDQUOT
CallID=("CallID"/"i")HCOLONcallid
callid=word["@"word]
CallInfo="CallInfo"HCOLONinfo*(COMMAinfo)
info=LAQUOTabsoluteURIRAQUOT*(SEMIinfoparam)
infoparam=("purpose"EQUAL("icon"/"info"
/"card"/token))/genericparam
Contact=("Contact"/"m")HCOLON
(STAR/(contactparam*(COMMAcontactparam)))
contactparam=(nameaddr/addrspec)*(SEMIcontactparams)
nameaddr=[displayname]LAQUOTaddrspecRAQUOT
addrspec=SIPURI/SIPSURI/absoluteURI
displayname=*(tokenLWS)/quotedstring
contactparams=cpq/cpexpires
/contactextension
cpq="q"EQUALqvalue
cpexpires="expires"EQUALdeltaseconds
contactextension=genericparam
deltaseconds=1*DIGIT
ContentDisposition="ContentDisposition"HCOLON
disptype*(SEMIdispparam)
disptype="render"/"session"/"icon"/"alert"
/dispextensiontoken
dispparam=handlingparam/genericparam
handlingparam="handling"EQUAL
("optional"/"required"
/otherhandling)
otherhandling=token
dispextensiontoken=token
ContentEncoding=("ContentEncoding"/"e")HCOLON
contentcoding*(COMMAcontentcoding)
ContentLanguage="ContentLanguage"HCOLON
languagetag*(COMMAlanguagetag)
languagetag=primarytag*(""subtag)
primarytag=1*8ALPHA
subtag=1*8ALPHA
ContentLength=("ContentLength"/"l")HCOLON1*DIGIT
ContentType=("ContentType"/"c")HCOLONmediatype
mediatype=mtypeSLASHmsubtype*(SEMImparameter)
mtype=discretetype/compositetype
discretetype="text"/"image"/"audio"/"video"
/"application"/extensiontoken
compositetype="message"/"multipart"/extensiontoken
extensiontoken=ietftoken/xtoken
ietftoken=token
xtoken="x"token
msubtype=extensiontoken/ianatoken
ianatoken=token
mparameter=mattributeEQUALmvalue
mattribute=token
mvalue=token/quotedstring
CSeq="CSeq"HCOLON1*DIGITLWSMethod
Date="Date"HCOLONSIPdate
SIPdate=rfc1123date
rfc1123date=wkday","SPdate1SPtimeSP"GMT"
date1=2DIGITSPmonthSP4DIGIT
daymonthyear(e.g.,02Jun1982)
time=2DIGIT":"2DIGIT":"2DIGIT
00:00:0023:59:59
wkday="Mon"/"Tue"/"Wed"
/"Thu"/"Fri"/"Sat"/"Sun"
month="Jan"/"Feb"/"Mar"/"Apr"
/"May"/"Jun"/"Jul"/"Aug"
/"Sep"/"Oct"/"Nov"/"Dec"
ErrorInfo="ErrorInfo"HCOLONerroruri*(COMMAerroruri)
erroruri=LAQUOTabsoluteURIRAQUOT*(SEMIgenericparam)
Expires="Expires"HCOLONdeltaseconds
From=("From"/"f")HCOLONfromspec
fromspec=(nameaddr/addrspec)
*(SEMIfromparam)
fromparam=tagparam/genericparam
tagparam="tag"EQUALtoken
InReplyTo="InReplyTo"HCOLONcallid*(COMMAcallid)
MaxForwards="MaxForwards"HCOLON1*DIGIT
MIMEVersion="MIMEVersion"HCOLON1*DIGIT"."1*DIGIT
MinExpires="MinExpires"HCOLONdeltaseconds
Organization="Organization"HCOLON[TEXTUTF8TRIM]
Priority="Priority"HCOLONpriorityvalue
priorityvalue="emergency"/"urgent"/"normal"
/"nonurgent"/otherpriority
otherpriority=token
ProxyAuthenticate="ProxyAuthenticate"HCOLONchallenge
challenge=("Digest"LWSdigestcln*(COMMAdigestcln))
/otherchallenge
otherchallenge=authschemeLWSauthparam
*(COMMAauthparam)
digestcln=realm/domain/nonce
/opaque/stale/algorithm
/qopoptions/authparam
realm="realm"EQUALrealmvalue
realmvalue=quotedstring
domain="domain"EQUALLDQUOTURI
*(1*SPURI)RDQUOT
URI=absoluteURI/abspath
nonce="nonce"EQUALnoncevalue
noncevalue=quotedstring
opaque="opaque"EQUALquotedstring
stale="stale"EQUAL("true"/"false")
algorithm="algorithm"EQUAL("MD5"/"MD5sess"
/token)
qopoptions="qop"EQUALLDQUOTqopvalue
*(","qopvalue)RDQUOT
qopvalue="auth"/"authint"/token
ProxyAuthorization="ProxyAuthorization"HCOLONcredentials
ProxyRequire="ProxyRequire"HCOLONoptiontag
*(COMMAoptiontag)
optiontag=token
RecordRoute="RecordRoute"HCOLONrecroute*(COMMArecroute)
recroute=nameaddr*(SEMIrrparam)
rrparam=genericparam
ReplyTo="ReplyTo"HCOLONrplytospec
rplytospec=(nameaddr/addrspec)
*(SEMIrplytoparam)
rplytoparam=genericparam
Require="Require"HCOLONoptiontag*(COMMAoptiontag)
RetryAfter="RetryAfter"HCOLONdeltaseconds
[comment]*(SEMIretryparam)
retryparam=("duration"EQUALdeltaseconds)
/genericparam
Route="Route"HCOLONrouteparam*(COMMArouteparam)
routeparam=nameaddr*(SEMIrrparam)
Server="Server"HCOLONserverval*(LWSserverval)
serverval=product/comment
product=token[SLASHproductversion]
productversion=token
Subject=("Subject"/"s")HCOLON[TEXTUTF8TRIM]
Supported=("Supported"/"k")HCOLON
[optiontag*(COMMAoptiontag)]
Timestamp="Timestamp"HCOLON1*(DIGIT)
["."*(DIGIT)][LWSdelay]
delay=*(DIGIT)["."*(DIGIT)]
To=("To"/"t")HCOLON(nameaddr
/addrspec)*(SEMItoparam)
toparam=tagparam/genericparam
Unsupported="Unsupported"HCOLONoptiontag*(COMMAoptiontag)
UserAgent="UserAgent"HCOLONserverval*(LWSserverval)
Via=("Via"/"v")HCOLONviaparm*(COMMAviaparm)
viaparm=sentprotocolLWSsentby*(SEMIviaparams)
viaparams=viattl/viamaddr
/viareceived/viabranch
/viaextension
viattl="ttl"EQUALttl
viamaddr="maddr"EQUALhost
viareceived="received"EQUAL(IPv4address/IPv6address)
viabranch="branch"EQUALtoken
viaextension=genericparam
sentprotocol=protocolnameSLASHprotocolversion
SLASHtransport
protocolname="SIP"/token
protocolversion=token
transport="UDP"/"TCP"/"TLS"/"SCTP"
/othertransport
sentby=host[COLONport]
ttl=1*3DIGIT0to255
Warning="Warning"HCOLONwarningvalue*(COMMAwarningvalue)
warningvalue=warncodeSPwarnagentSPwarntext
warncode=3DIGIT
warnagent=hostport/pseudonym
thenameorpseudonymoftheserveradding
theWarningheader,foruseindebugging
warntext=quotedstring
pseudonym=token
WWWAuthenticate="WWWAuthenticate"HCOLONchallenge
extensionheader=headernameHCOLONheadervalue
headername=token
headervalue=*(TEXTUTF8char/UTF8CONT/LWS)
messagebody=*OCTET
26SecurityConsiderations:ThreatModelandSecurityUsage
Recommendations
SIPisnotaneasyprotocoltosecure.Itsuseofintermediaries,
itsmultifacetedtrustrelationships,itsexpectedusagebetween
elementswithnotrustatall,anditsusertouseroperationmake
securityfarfromtrivial.Securitysolutionsareneededthatare
deployabletoday,withoutextensivecoordination,inawidevariety
ofenvironmentsandusages.Inordertomeetthesediverseneeds,
severaldistinctmechanismsapplicabletodifferentaspectsand
usagesofSIPwillberequired.
NotethatthesecurityofSIPsignalingitselfhasnobearingonthe
securityofprotocolsusedinconcertwithSIPsuchasRTP,orwith
thesecurityimplicationsofanyspecificbodiesSIPmightcarry
(althoughMIMEsecurityplaysasubstantialroleinsecuringSIP).
Anymediaassociatedwithasessioncanbeencryptedendtoend
independentlyofanyassociatedSIPsignaling.Mediaencryptionis
outsidethescopeofthisdocument.
Theconsiderationsthatfollowfirstexamineasetofclassicthreat
modelsthatbroadlyidentifythesecurityneedsofSIP.Thesetof
securityservicesrequiredtoaddressthesethreatsisthendetailed,
followedbyanexplanationofseveralsecuritymechanismsthatcanbe
usedtoprovidetheseservices.Next,therequirementsfor
implementersofSIPareenumerated,alongwithexemplarydeployments
inwhichthesesecuritymechanismscouldbeusedtoimprovethe
securityofSIP.Somenotesonprivacyconcludethissection.
26.1AttacksandThreatModels
Thissectiondetailssomethreatsthatshouldbecommontomost
deploymentsofSIP.Thesethreatshavebeenchosenspecificallyto
illustrateeachofthesecurityservicesthatSIPrequires.
Thefollowingexamplesbynomeansprovideanexhaustivelistofthe
threatsagainstSIPrather,theseare"classic"threatsthat
demonstratetheneedforparticularsecurityservicesthatcan
potentiallypreventwholecategoriesofthreats.
Theseattacksassumeanenvironmentinwhichattackerscan
potentiallyreadanypacketonthenetworkitisanticipatedthat
SIPwillfrequentlybeusedonthepublicInternet.Attackersonthe
networkmaybeabletomodifypackets(perhapsatsomecompromised
intermediary).Attackersmaywishtostealservices,eavesdropon
communications,ordisruptsessions.
26.1.1RegistrationHijacking
TheSIPregistrationmechanismallowsauseragenttoidentifyitself
toaregistrarasadeviceatwhichauser(designatedbyanaddress
ofrecord)islocated.Aregistrarassessestheidentityassertedin
theFromheaderfieldofaREGISTERmessagetodeterminewhetherthis
requestcanmodifythecontactaddressesassociatedwiththe
addressofrecordintheToheaderfield.Whilethesetwofieldsare
frequentlythesame,therearemanyvaliddeploymentsinwhicha
thirdpartymayregistercontactsonauser'sbehalf.
TheFromheaderfieldofaSIPrequest,however,canbemodified
arbitrarilybytheownerofaUA,andthisopensthedoorto
maliciousregistrations.Anattackerthatsuccessfullyimpersonates
apartyauthorizedtochangecontactsassociatedwithanaddressof
recordcould,forexample,deregisterallexistingcontactsfora
URIandthenregistertheirowndeviceastheappropriatecontact
address,therebydirectingallrequestsfortheaffectedusertothe
attacker'sdevice.
Thisthreatbelongstoafamilyofthreatsthatrelyontheabsence
ofcryptographicassuranceofarequest'soriginator.AnySIPUAS
thatrepresentsavaluableservice(agatewaythatinterworksSIP
requestswithtraditionaltelephonecalls,forexample)mightwantto
controlaccesstoitsresourcesbyauthenticatingrequeststhatit
receives.EvenenduserUAs,forexampleSIPphones,havean
interestinascertainingtheidentitiesoforiginatorsofrequests.
Thisthreatdemonstratestheneedforsecurityservicesthatenable
SIPentitiestoauthenticatetheoriginatorsofrequests.
26.1.2ImpersonatingaServer
Thedomaintowhicharequestisdestinedisgenerallyspecifiedin
theRequestURI.UAscommonlycontactaserverinthisdomain
directlyinordertodeliverarequest.However,thereisalwaysa
possibilitythatanattackercouldimpersonatetheremoteserver,and
thattheUA'srequestcouldbeinterceptedbysomeotherparty.
Forexample,consideracaseinwhicharedirectserveratone
domain,chicago.com,impersonatesaredirectserveratanother
domain,biloxi.com.Auseragentsendsarequesttobiloxi.com,but
theredirectserveratchicago.comanswerswithaforgedresponse
thathasappropriateSIPheaderfieldsforaresponsefrom
biloxi.com.Theforgedcontactaddressesintheredirectionresponse
coulddirecttheoriginatingUAtoinappropriateorinsecure
resources,orsimplypreventrequestsforbiloxi.comfromsucceeding.
Thisfamilyofthreatshasavastmembership,manyofwhichare
critical.Asaconversetotheregistrationhijackingthreat,
considerthecaseinwhicharegistrationsenttobiloxi.comis
interceptedbychicago.com,whichrepliestotheintercepted
registrationwithaforged301(MovedPermanently)response.This
responsemightseemtocomefrombiloxi.comyetdesignatechicago.com
astheappropriateregistrar.AllfutureREGISTERrequestsfromthe
originatingUAwouldthengotochicago.com.
PreventionofthisthreatrequiresameansbywhichUAscan
authenticatetheserverstowhomtheysendrequests.
26.1.3TamperingwithMessageBodies
Asamatterofcourse,SIPUAsrouterequeststhroughtrustedproxy
servers.Regardlessofhowthattrustisestablished(authentication
ofproxiesisdiscussedelsewhereinthissection),aUAmaytrusta
proxyservertoroutearequest,butnottoinspectorpossibly
modifythebodiescontainedinthatrequest.
ConsideraUAthatisusingSIPmessagebodiestocommunicatesession
encryptionkeysforamediasession.Althoughittruststheproxy
serverofthedomainitiscontactingtodeliversignalingproperly,
itmaynotwanttheadministratorsofthatdomaintobecapableof
decryptinganysubsequentmediasession.Worseyet,iftheproxy
serverwereactivelymalicious,itcouldmodifythesessionkey,
eitheractingasamaninthemiddle,orperhapschangingthe
securitycharacteristicsrequestedbytheoriginatingUA.
Thisfamilyofthreatsappliesnotonlytosessionkeys,buttomost
conceivableformsofcontentcarriedendtoendinSIP.Thesemight
includeMIMEbodiesthatshouldberenderedtotheuser,SDP,or
encapsulatedtelephonysignals,amongothers.Attackersmight
attempttomodifySDPbodies,forexample,inordertopointRTP
mediastreamstoawiretappingdeviceinordertoeavesdropon
subsequentvoicecommunications.
AlsonotethatsomeheaderfieldsinSIParemeaningfulendtoend,
forexample,Subject.UAsmightbeprotectiveoftheseheaderfields
aswellasbodies(amaliciousintermediarychangingtheSubject
headerfieldmightmakeanimportantrequestappeartobespam,for
example).However,sincemanyheaderfieldsarelegitimately
inspectedoralteredbyproxyserversasarequestisrouted,notall
headerfieldsshouldbesecuredendtoend.
Forthesereasons,theUAmightwanttosecureSIPmessagebodies,
andinsomelimitedcasesheaderfields,endtoend.Thesecurity
servicesrequiredforbodiesincludeconfidentiality,integrity,and
authentication.Theseendtoendservicesshouldbeindependentof
themeansusedtosecureinteractionswithintermediariessuchas
proxyservers.
26.1.4TearingDownSessions
Onceadialoghasbeenestablishedbyinitialmessaging,subsequent
requestscanbesentthatmodifythestateofthedialogand/or
session.Itiscriticalthatprincipalsinasessioncanbecertain
thatsuchrequestsarenotforgedbyattackers.
Consideracaseinwhichathirdpartyattackercapturessomeinitial
messagesinadialogsharedbytwopartiesinordertolearnthe
parametersofthesession(Totag,Fromtag,andsoforth)andthen
insertsaBYErequestintothesession.Theattackercouldoptto
forgetherequestsuchthatitseemedtocomefromeither
participant.OncetheBYEisreceivedbyitstarget,thesession
willbetorndownprematurely.
Similarmidsessionthreatsincludethetransmissionofforgedre
INVITEsthatalterthesession(possiblytoreducesessionsecurity
orredirectmediastreamsaspartofawiretappingattack).
Themosteffectivecountermeasuretothisthreatisthe
authenticationofthesenderoftheBYE.Inthisinstance,the
recipientneedsonlyknowthattheBYEcamefromthesamepartywith
whomthecorrespondingdialogwasestablished(asopposedto
ascertainingtheabsoluteidentityofthesender).Also,ifthe
attackerisunabletolearntheparametersofthesessiondueto
confidentiality,itwouldnotbepossibletoforgetheBYE.However,
someintermediaries(likeproxyservers)willneedtoinspectthose
parametersasthesessionisestablished.
26.1.5DenialofServiceandAmplification
Denialofserviceattacksfocusonrenderingaparticularnetwork
elementunavailable,usuallybydirectinganexcessiveamountof
networktrafficatitsinterfaces.Adistributeddenialofservice
attackallowsonenetworkusertocausemultiplenetworkhoststo
floodatargethostwithalargeamountofnetworktraffic.
Inmanyarchitectures,SIPproxyserversfacethepublicInternetin
ordertoacceptrequestsfromworldwideIPendpoints.SIPcreatesa
numberofpotentialopportunitiesfordistributeddenialofservice
attacksthatmustberecognizedandaddressedbytheimplementersand
operatorsofSIPsystems.
Attackerscancreatebogusrequeststhatcontainafalsifiedsource
IPaddressandacorrespondingViaheaderfieldthatidentifya
targetedhostastheoriginatoroftherequestandthensendthis
requesttoalargenumberofSIPnetworkelements,therebyusing
haplessSIPUAsorproxiestogeneratedenialofservicetraffic
aimedatthetarget.
Similarly,attackersmightusefalsifiedRouteheaderfieldvaluesin
arequestthatidentifythetargethostandthensendsuchmessages
toforkingproxiesthatwillamplifymessagingsenttothetarget.
RecordRoutecouldbeusedtosimilareffectwhentheattackeris
certainthattheSIPdialoginitiatedbytherequestwillresultin
numeroustransactionsoriginatinginthebackwardsdirection.
AnumberofdenialofserviceattacksopenupifREGISTERrequests
arenotproperlyauthenticatedandauthorizedbyregistrars.
Attackerscouldderegistersomeorallusersinanadministrative
domain,therebypreventingtheseusersfrombeinginvitedtonew
sessions.Anattackercouldalsoregisteralargenumberofcontacts
designatingthesamehostforagivenaddressofrecordinorderto
usetheregistrarandanyassociatedproxyserversasamplifiersina
denialofserviceattack.Attackersmightalsoattempttodeplete
availablememoryanddiskresourcesofaregistrarbyregistering
hugenumbersofbindings.
TheuseofmulticasttotransmitSIPrequestscangreatlyincrease
thepotentialfordenialofserviceattacks.
Theseproblemsdemonstrateageneralneedtodefinearchitectures
thatminimizetherisksofdenialofservice,andtheneedtobe
mindfulinrecommendationsforsecuritymechanismsofthisclassof
attacks.
26.2SecurityMechanisms
Fromthethreatsdescribedabove,wegatherthatthefundamental
securityservicesrequiredfortheSIPprotocolare:preservingthe
confidentialityandintegrityofmessaging,preventingreplayattacks
ormessagespoofing,providingfortheauthenticationandprivacyof
theparticipantsinasession,andpreventingdenialofservice
attacks.BodieswithinSIPmessagesseparatelyrequirethesecurity
servicesofconfidentiality,integrity,andauthentication.
RatherthandefiningnewsecuritymechanismsspecifictoSIP,SIP
reuseswhereverpossibleexistingsecuritymodelsderivedfromthe
HTTPandSMTPspace.
Fullencryptionofmessagesprovidesthebestmeanstopreservethe
confidentialityofsignalingitcanalsoguaranteethatmessages
arenotmodifiedbyanymaliciousintermediaries.However,SIP
requestsandresponsescannotbenaivelyencryptedendtoendin
theirentiretybecausemessagefieldssuchastheRequestURI,Route,
andVianeedtobevisibletoproxiesinmostnetworkarchitectures
sothatSIPrequestsareroutedcorrectly.Notethatproxyservers
needtomodifysomefeaturesofmessagesaswell(suchasaddingVia
headerfieldvalues)inorderforSIPtofunction.Proxyservers
mustthereforebetrusted,tosomedegree,bySIPUAs.Tothis
purpose,lowlayersecuritymechanismsforSIParerecommended,which
encrypttheentireSIPrequestsorresponsesonthewireonahop
byhopbasis,andthatallowendpointstoverifytheidentityof
proxyserverstowhomtheysendrequests.
SIPentitiesalsohaveaneedtoidentifyoneanotherinasecure
fashion.WhenaSIPendpointassertstheidentityofitsusertoa
peerUAortoaproxyserver,thatidentityshouldinsomewaybe
verifiable.Acryptographicauthenticationmechanismisprovidedin
SIPtoaddressthisrequirement.
AnindependentsecuritymechanismforSIPmessagebodiessuppliesan
alternativemeansofendtoendmutualauthentication,aswellas
providingalimitonthedegreetowhichuseragentsmusttrust
intermediaries.
26.2.1TransportandNetworkLayerSecurity
Transportornetworklayersecurityencryptssignalingtraffic,
guaranteeingmessageconfidentialityandintegrity.
Oftentimes,certificatesareusedintheestablishmentoflowerlayer
security,andthesecertificatescanalsobeusedtoprovideameans
ofauthenticationinmanyarchitectures.
Twopopularalternativesforprovidingsecurityatthetransportand
networklayerare,respectively,TLS[25]andIPSec[26].
IPSecisasetofnetworklayerprotocoltoolsthatcollectivelycan
beusedasasecurereplacementfortraditionalIP(Internet
Protocol).IPSecismostcommonlyusedinarchitecturesinwhicha
setofhostsoradministrativedomainshaveanexistingtrust
relationshipwithoneanother.IPSecisusuallyimplementedatthe
operatingsystemlevelinahost,oronasecuritygatewaythat
providesconfidentialityandintegrityforalltrafficitreceives
fromaparticularinterface(asinaVPNarchitecture).IPSeccan
alsobeusedonahopbyhopbasis.
InmanyarchitecturesIPSecdoesnotrequireintegrationwithSIP
applicationsIPSecisperhapsbestsuitedtodeploymentsinwhich
addingsecuritydirectlytoSIPhostswouldbearduous.UAsthat
haveapresharedkeyingrelationshipwiththeirfirsthopproxy
serverarealsogoodcandidatestouseIPSec.Anydeploymentof
IPSecforSIPwouldrequireanIPSecprofiledescribingtheprotocol
toolsthatwouldberequiredtosecureSIP.Nosuchprofileisgiven
inthisdocument.
TLSprovidestransportlayersecurityoverconnectionoriented
protocols(forthepurposesofthisdocument,TCP)"tls"(signifying
TLSoverTCP)canbespecifiedasthedesiredtransportprotocol
withinaViaheaderfieldvalueoraSIPURI.TLSismostsuitedto
architecturesinwhichhopbyhopsecurityisrequiredbetweenhosts
withnopreexistingtrustassociation.Forexample,Alicetrusts
herlocalproxyserver,whichafteracertificateexchangedecidesto
trustBob'slocalproxyserver,whichBobtrusts,henceBobandAlice
cancommunicatesecurely.
TLSmustbetightlycoupledwithaSIPapplication.Notethat
transportmechanismsarespecifiedonahopbyhopbasisinSIP,thus
aUAthatsendsrequestsoverTLStoaproxyserverhasnoassurance
thatTLSwillbeusedendtoend.
TheTLS_RSA_WITH_AES_128_CBC_SHAciphersuite[6]MUSTbesupportedat
aminimumbyimplementerswhenTLSisusedinaSIPapplication.For
purposesofbackwardscompatibility,proxyservers,redirectservers,
andregistrarsSHOULDsupportTLS_RSA_WITH_3DES_EDE_CBC_SHA.
ImplementersMAYalsosupportanyotherciphersuite.
26.2.2SIPSURIScheme
TheSIPSURIschemeadherestothesyntaxoftheSIPURI(described
in19),althoughtheschemestringis"sips"ratherthan"sip".The
semanticsofSIPSareverydifferentfromtheSIPURI,however.SIPS
allowsresourcestospecifythattheyshouldbereachedsecurely.
ASIPSURIcanbeusedasanaddressofrecordforaparticularuser
theURIbywhichtheuseriscanonicallyknown(ontheirbusiness
cards,intheFromheaderfieldoftheirrequests,intheToheader
fieldofREGISTERrequests).WhenusedastheRequestURIofa
request,theSIPSschemesignifiesthateachhopoverwhichthe
requestisforwarded,untiltherequestreachestheSIPentity
responsibleforthedomainportionoftheRequestURI,mustbe
securedwithTLSonceitreachesthedomaininquestionitis
handledinaccordancewithlocalsecurityandroutingpolicy,quite
possiblyusingTLSforanylasthoptoaUAS.Whenusedbythe
originatorofarequest(aswouldbethecaseiftheyemployedaSIPS
URIastheaddressofrecordofthetarget),SIPSdictatesthatthe
entirerequestpathtothetargetdomainbesosecured.
TheSIPSschemeisapplicabletomanyoftheotherwaysinwhichSIP
URIsareusedinSIPtodayinadditiontotheRequestURI,including
inaddressesofrecord,contactaddresses(thecontentsofContact
headers,includingthoseofREGISTERmethods),andRouteheaders.In
eachinstance,theSIPSURIschemeallowstheseexistingfieldsto
designatesecureresources.ThemannerinwhichaSIPSURIis
dereferencedinanyofthesecontextshasitsownsecurityproperties
whicharedetailedin[4].
TheuseofSIPSinparticularentailsthatmutualTLSauthentication
SHOULDbeemployed,asSHOULDtheciphersuite
TLS_RSA_WITH_AES_128_CBC_SHA.Certificatesreceivedinthe
authenticationprocessSHOULDbevalidatedwithrootcertificates
heldbytheclientfailuretovalidateacertificateSHOULDresult
inthefailureoftherequest.
NotethatintheSIPSURIscheme,transportisindependentofTLS,
andthus"sips:alice@atlanta.comtransport=tcp"and
"sips:alice@atlanta.comtransport=sctp"arebothvalid(although
notethatUDPisnotavalidtransportforSIPS).Theuseof
"transport=tls"hasconsequentlybeendeprecated,partlybecause
itwasspecifictoasinglehopoftherequest.Thisisachange
sinceRFC2543.
UsersthatdistributeaSIPSURIasanaddressofrecordmayelectto
operatedevicesthatrefuserequestsoverinsecuretransports.
26.2.3HTTPAuthentication
SIPprovidesachallengecapability,basedonHTTPauthentication,
thatreliesonthe401and407responsecodesaswellasheader
fieldsforcarryingchallengesandcredentials.Withoutsignificant
modification,thereuseoftheHTTPDigestauthenticationschemein
SIPallowsforreplayprotectionandonewayauthentication.
TheusageofDigestauthenticationinSIPisdetailedinSection22.
26.2.4S/MIME
Asisdiscussedabove,encryptingentireSIPmessagesendtoendfor
thepurposeofconfidentialityisnotappropriatebecausenetwork
intermediaries(likeproxyservers)needtoviewcertainheader
fieldsinordertoroutemessagescorrectly,andifthese
intermediariesareexcludedfromsecurityassociations,thenSIP
messageswillessentiallybenonroutable.
However,S/MIMEallowsSIPUAstoencryptMIMEbodieswithinSIP,
securingthesebodiesendtoendwithoutaffectingmessageheaders.
S/MIMEcanprovideendtoendconfidentialityandintegrityfor
messagebodies,aswellasmutualauthentication.Itisalso
possibletouseS/MIMEtoprovideaformofintegrityand
confidentialityforSIPheaderfieldsthroughSIPmessagetunneling.
TheusageofS/MIMEinSIPisdetailedinSection23.
26.3ImplementingSecurityMechanisms
26.3.1RequirementsforImplementersofSIP
Proxyservers,redirectservers,andregistrarsMUSTimplementTLS,
andMUSTsupportbothmutualandonewayauthentication.Itis
stronglyRECOMMENDEDthatUAsbecapableinitiatingTLSUAsMAYalso
becapableofactingasaTLSserver.Proxyservers,redirect
servers,andregistrarsSHOULDpossessasitecertificatewhose
subjectcorrespondstotheircanonicalhostname.UAsMAYhave
certificatesoftheirownformutualauthenticationwithTLS,butno
provisionsaresetforthinthisdocumentfortheiruse.AllSIP
elementsthatsupportTLSMUSThaveamechanismforvalidating
certificatesreceivedduringTLSnegotiationthisentailspossession
ofoneormorerootcertificatesissuedbycertificateauthorities
(preferablywellknowndistributorsofsitecertificatescomparable
tothosethatissuerootcertificatesforwebbrowsers).
AllSIPelementsthatsupportTLSMUSTalsosupporttheSIPSURI
scheme.
Proxyservers,redirectservers,registrars,andUAsMAYalso
implementIPSecorotherlowerlayersecurityprotocols.
WhenaUAattemptstocontactaproxyserver,redirectserver,or
registrar,theUACSHOULDinitiateaTLSconnectionoverwhichit
willsendSIPmessages.Insomearchitectures,UASsMAYreceive
requestsoversuchTLSconnectionsaswell.
Proxyservers,redirectservers,registrars,andUAsMUSTimplement
DigestAuthorization,encompassingalloftheaspectsrequiredin22.
Proxyservers,redirectservers,andregistrarsSHOULDbeconfigured
withatleastoneDigestrealm,andatleastone"realm"string
supportedbyagivenserverSHOULDcorrespondtotheserver's
hostnameordomainname.
UAsMAYsupportthesigningandencryptingofMIMEbodies,and
transferenceofcredentialswithS/MIMEasdescribedinSection23.
IfaUAholdsoneormorerootcertificatesofcertificate
authoritiesinordertovalidatecertificatesforTLSorIPSec,it
SHOULDbecapableofreusingthesetoverifyS/MIMEcertificates,as
appropriate.AUAMAYholdrootcertificatesspecificallyfor
validatingS/MIMEcertificates.
Notethatisitanticipatedthatfuturesecurityextensionsmay
upgradethenormativestrengthassociatedwithS/MIMEasS/MIME
implementationsappearandtheproblemspacebecomesbetter
understood.
26.3.2SecuritySolutions
Theoperationofthesesecuritymechanismsinconcertcanfollowthe
existingwebandemailsecuritymodelstosomedegree.Atahigh
level,UAsauthenticatethemselvestoservers(proxyservers,
redirectservers,andregistrars)withaDigestusernameand
passwordserversauthenticatethemselvestoUAsonehopaway,orto
anotherserveronehopaway(andviceversa),withasitecertificate
deliveredbyTLS.
Onapeertopeerlevel,UAstrustthenetworktoauthenticateone
anotherordinarilyhowever,S/MIMEcanalsobeusedtoprovide
directauthenticationwhenthenetworkdoesnot,orifthenetwork
itselfisnottrusted.
Thefollowingisanillustrativeexampleinwhichthesesecurity
mechanismsareusedbyvariousUAsandserverstopreventthesorts
ofthreatsdescribedinSection26.1.Whileimplementersandnetwork
administratorsMAYfollowthenormativeguidelinesgiveninthe
remainderofthissection,theseareprovidedonlyasexample
implementations.
26.3.2.1Registration
WhenaUAcomesonlineandregisterswithitslocaladministrative
domain,itSHOULDestablishaTLSconnectionwithitsregistrar
(Section10describeshowtheUAreachesitsregistrar).The
registrarSHOULDofferacertificatetotheUA,andthesite
identifiedbythecertificateMUSTcorrespondwiththedomainin
whichtheUAintendstoregisterforexample,iftheUAintendsto
registertheaddressofrecord'alice@atlanta.com',thesite
certificatemustidentifyahostwithintheatlanta.comdomain(such
assip.atlanta.com).WhenitreceivestheTLSCertificatemessage,
theUASHOULDverifythecertificateandinspectthesiteidentified
bythecertificate.Ifthecertificateisinvalid,revoked,orifit
doesnotidentifytheappropriateparty,theUAMUSTNOTsendthe
REGISTERmessageandotherwiseproceedwiththeregistration.
Whenavalidcertificatehasbeenprovidedbytheregistrar,the
UAknowsthattheregistrarisnotanattackerwhomightredirect
theUA,stealpasswords,orattemptanysimilarattacks.
TheUAthencreatesaREGISTERrequestthatSHOULDbeaddressedtoa
RequestURIcorrespondingtothesitecertificatereceivedfromthe
registrar.WhentheUAsendstheREGISTERrequestovertheexisting
TLSconnection,theregistrarSHOULDchallengetherequestwitha401
(ProxyAuthenticationRequired)response.The"realm"parameter
withintheProxyAuthenticateheaderfieldoftheresponseSHOULD
correspondtothedomainpreviouslygivenbythesitecertificate.
WhentheUACreceivesthechallenge,itSHOULDeitherprompttheuser
forcredentialsortakeanappropriatecredentialfromakeyring
correspondingtothe"realm"parameterinthechallenge.The
usernameofthiscredentialSHOULDcorrespondwiththe"userinfo"
portionoftheURIintheToheaderfieldoftheREGISTERrequest.
OncetheDigestcredentialshavebeeninsertedintoanappropriate
ProxyAuthorizationheaderfield,theREGISTERshouldberesubmitted
totheregistrar.
Sincetheregistrarrequirestheuseragenttoauthenticate
itself,itwouldbedifficultforanattackertoforgeREGISTER
requestsfortheuser'saddressofrecord.Alsonotethatsince
theREGISTERissentoveraconfidentialTLSconnection,attackers
willnotbeabletointercepttheREGISTERtorecordcredentials
foranypossiblereplayattack.
Oncetheregistrationhasbeenacceptedbytheregistrar,theUA
SHOULDleavethisTLSconnectionopenprovidedthattheregistrar
alsoactsastheproxyservertowhichrequestsaresentforusersin
thisadministrativedomain.TheexistingTLSconnectionwillbe
reusedtodeliverincomingrequeststotheUAthathasjustcompleted
registration.
BecausetheUAhasalreadyauthenticatedtheserverontheother
sideoftheTLSconnection,allrequeststhatcomeoverthis
connectionareknowntohavepassedthroughtheproxyserver
attackerscannotcreatespoofedrequeststhatappeartohavebeen
sentthroughthatproxyserver.
26.3.2.2InterdomainRequests
Nowlet'ssaythatAlice'sUAwouldliketoinitiateasessionwitha
userinaremoteadministrativedomain,namely"bob@biloxi.com".We
willalsosaythatthelocaladministrativedomain(atlanta.com)has
alocaloutboundproxy.
Theproxyserverthathandlesinboundrequestsforanadministrative
domainMAYalsoactasalocaloutboundproxyforsimplicity'ssake
we'llassumethistobethecaseforatlanta.com(otherwisetheuser
agentwouldinitiateanewTLSconnectiontoaseparateserverat
thispoint).Assumingthattheclienthascompletedtheregistration
processdescribedintheprecedingsection,itSHOULDreusetheTLS
connectiontothelocalproxyserverwhenitsendsanINVITErequest
toanotheruser.TheUASHOULDreusecachedcredentialsinthe
INVITEtoavoidpromptingtheuserunnecessarily.
Whenthelocaloutboundproxyserverhasvalidatedthecredentials
presentedbytheUAintheINVITE,itSHOULDinspecttheRequestURI
todeterminehowthemessageshouldberouted(see[4]).Ifthe
"domainname"portionoftheRequestURIhadcorrespondedtothelocal
domain(atlanta.com)ratherthanbiloxi.com,thentheproxyserver
wouldhaveconsulteditslocationservicetodeterminehowbestto
reachtherequesteduser.
Had"alice@atlanta.com"beenattemptingtocontact,say,
"alex@atlanta.com",thelocalproxywouldhaveproxiedtothe
requesttotheTLSconnectionAlexhadestablishedwiththe
registrarwhenheregistered.SinceAlexwouldreceivethis
requestoverhisauthenticatedchannel,hewouldbeassuredthat
Alice'srequesthadbeenauthorizedbytheproxyserverofthe
localadministrativedomain.
However,inthisinstancetheRequestURIdesignatesaremotedomain.
Thelocaloutboundproxyserveratatlanta.comSHOULDtherefore
establishaTLSconnectionwiththeremoteproxyserverat
biloxi.com.SincebothoftheparticipantsinthisTLSconnection
areserversthatpossesssitecertificates,mutualTLSauthentication
SHOULDoccur.EachsideoftheconnectionSHOULDverifyandinspect
thecertificateoftheother,notingthedomainnamethatappearsin
thecertificateforcomparisonwiththeheaderfieldsofSIP
messages.Theatlanta.comproxyserver,forexample,SHOULDverify
atthisstagethatthecertificatereceivedfromtheremoteside
correspondswiththebiloxi.comdomain.Onceithasdoneso,andTLS
negotiationhascompleted,resultinginasecurechannelbetweenthe
twoproxies,theatlanta.comproxycanforwardtheINVITErequestto
biloxi.com.
Theproxyserveratbiloxi.comSHOULDinspectthecertificateofthe
proxyserveratatlanta.cominturnandcomparethedomainasserted
bythecertificatewiththe"domainname"portionoftheFromheader
fieldintheINVITErequest.ThebiloxiproxyMAYhaveastrict
securitypolicythatrequiresittorejectrequeststhatdonotmatch
theadministrativedomainfromwhichtheyhavebeenproxied.
SuchsecuritypoliciescouldbeinstitutedtopreventtheSIP
equivalentofSMTP'openrelays'thatarefrequentlyexploitedto
generatespam.
Thispolicy,however,onlyguaranteesthattherequestcamefromthe
domainitascribestoitselfitdoesnotallowbiloxi.comto
ascertainhowatlanta.comauthenticatedAlice.Onlyifbiloxi.com
hassomeotherwayofknowingatlanta.com'sauthenticationpolicies
coulditpossiblyascertainhowAliceprovedheridentity.
biloxi.commighttheninstituteanevenstricterpolicythatforbids
requeststhatcomefromdomainsthatarenotknownadministratively
toshareacommonauthenticationpolicywithbiloxi.com.
OncetheINVITEhasbeenapprovedbythebiloxiproxy,theproxy
serverSHOULDidentifytheexistingTLSchannel,ifany,associated
withtheusertargetedbythisrequest(inthiscase
"bob@biloxi.com").TheINVITEshouldbeproxiedthroughthischannel
toBob.SincetherequestisreceivedoveraTLSconnectionthathad
previouslybeenauthenticatedasthebiloxiproxy,Bobknowsthatthe
Fromheaderfieldwasnottamperedwithandthatatlanta.comhas
validatedAlice,althoughnotnecessarilywhetherornottotrust
Alice'sidentity.
Beforetheyforwardtherequest,bothproxyserversSHOULDadda
RecordRouteheaderfieldtotherequestsothatallfuturerequests
inthisdialogwillpassthroughtheproxyservers.Theproxy
serverscantherebycontinuetoprovidesecurityservicesforthe
lifetimeofthisdialog.Iftheproxyserversdonotaddthemselves
totheRecordRoute,futuremessageswillpassdirectlyendtoend
betweenAliceandBobwithoutanysecurityservices(unlessthetwo
partiesagreeonsomeindependentendtoendsecuritysuchas
S/MIME).InthisrespecttheSIPtrapezoidmodelcanprovideanice
structurewhereconventionsofagreementbetweenthesiteproxiescan
provideareasonablysecurechannelbetweenAliceandBob.
Anattackerpreyingonthisarchitecturewould,forexample,be
unabletoforgeaBYErequestandinsertitintothesignaling
streambetweenBobandAlicebecausetheattackerhasnowayof
ascertainingtheparametersofthesessionandalsobecausethe
integritymechanismtransitivelyprotectsthetrafficbetween
AliceandBob.
26.3.2.3PeertoPeerRequests
Alternatively,consideraUAassertingtheidentity
"carol@chicago.com"thathasnolocaloutboundproxy.WhenCarol
wishestosendanINVITEto"bob@biloxi.com",herUASHOULDinitiate
aTLSconnectionwiththebiloxiproxydirectly(usingthemechanism
describedin[4]todeterminehowtobesttoreachthegiven
RequestURI).WhenherUAreceivesacertificatefromthebiloxi
proxy,itSHOULDbeverifiednormallybeforeshepassesherINVITE
acrosstheTLSconnection.However,Carolhasnomeansofproving
heridentitytothebiloxiproxy,butshedoeshaveaCMSdetached
signatureovera"message/sip"bodyintheINVITE.Itisunlikelyin
thisinstancethatCarolwouldhaveanycredentialsinthebiloxi.com
realm,sinceshehasnoformalassociationwithbiloxi.com.The
biloxiproxyMAYalsohaveastrictpolicythatprecludesitfrom
evenbotheringtochallengerequeststhatdonothavebiloxi.comin
the"domainname"portionoftheFromheaderfieldittreatsthese
usersasunauthenticated.
ThebiloxiproxyhasapolicyforBobthatallnonauthenticated
requestsshouldberedirectedtotheappropriatecontactaddress
registeredagainst'bob@biloxi.com',namely<sip:bob@192.0.2.4>.
CarolreceivestheredirectionresponseovertheTLSconnectionshe
establishedwiththebiloxiproxy,soshetruststheveracityofthe
contactaddress.
CarolSHOULDthenestablishaTCPconnectionwiththedesignated
addressandsendanewINVITEwithaRequestURIcontainingthe
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
Inordertominimizetheriskofadenialofserviceattackagainst
architecturesusingthesesecuritysolutions,implementersshould
takenoteofthefollowingguidelines.
WhenthehostonwhichaSIPproxyserverisoperatingisroutable
fromthepublicInternet,itSHOULDbedeployedinanadministrative
domainwithdefensiveoperationalpolicies(blockingsourcerouted
traffic,preferablyfilteringpingtraffic).BothTLSandIPSeccan
alsomakeuseofbastionhostsattheedgesofadministrativedomains
thatparticipateinthesecurityassociationstoaggregatesecure
tunnelsandsockets.Thesebastionhostscanalsotakethebruntof
denialofserviceattacks,ensuringthatSIPhostswithinthe
administrativedomainarenotencumberedwithsuperfluousmessaging.
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,theyofferprotectionoftheRequestURIandthemethod
ofamessage,butnotforanyoftheheaderfieldsthatUAswould
mostlikelywishtosecure.
TheexistingreplayprotectionmechanismsdescribedinRFC2617also
havesomelimitationsforSIP.Thenextnoncemechanism,for
example,doesnotsupportpipelinedrequests.Thenoncecount
mechanismshouldbeusedforreplayprotection.
AnotherlimitationofHTTPDigestisthescopeofrealms.Digestis
valuablewhenauserwantstoauthenticatethemselvestoaresource
withwhichtheyhaveapreexistingassociation,likeaservice
providerofwhichtheuserisacustomer(whichisquiteacommon
scenarioandthusDigestprovidesanextremelyusefulfunction).By
wayofcontrast,thescopeofTLSisinterdomainormultirealm,since
certificatesareoftengloballyverifiable,sothattheUAcan
authenticatetheserverwithnopreexistingassociation.
26.4.2S/MIME
ThelargestoutstandingdefectwiththeS/MIMEmechanismisthelack
ofaprevalentpublickeyinfrastructureforendusers.Ifself
signedcertificates(orcertificatesthatcannotbeverifiedbyone
oftheparticipantsinadialog)areused,theSIPbasedkeyexchange
mechanismdescribedinSection23.2issusceptibletoamaninthe
middleattackwithwhichanattackercanpotentiallyinspectand
modifyS/MIMEbodies.Theattackerneedstointerceptthefirst
exchangeofkeysbetweenthetwopartiesinadialog,removethe
existingCMSdetachedsignaturesfromtherequestandresponse,and
insertadifferentCMSdetachedsignaturecontainingacertificate
suppliedbytheattacker(butwhichseemstobeacertificateforthe
properaddressofrecord).Eachpartywillthinktheyhaveexchanged
keyswiththeother,wheninfacteachhasthepublickeyofthe
attacker.
Itisimportanttonotethattheattackercanonlyleveragethis
vulnerabilityonthefirstexchangeofkeysbetweentwopartieson
subsequentoccasions,thealterationofthekeywouldbenoticeable
totheUAs.Itwouldalsobedifficultfortheattackertoremainin
thepathofallfuturedialogsbetweenthetwopartiesovertime(as
potentiallydays,weeks,oryearspass).
SSHissusceptibletothesamemaninthemiddleattackonthefirst
exchangeofkeyshowever,itiswidelyacknowledgedthatwhileSSH
isnotperfect,itdoesimprovethesecurityofconnections.Theuse
ofkeyfingerprintscouldprovidesomeassistancetoSIP,justasit
doesforSSH.Forexample,iftwopartiesuseSIPtoestablisha
voicecommunicationssession,eachcouldreadoffthefingerprintof
thekeytheyreceivedfromtheother,whichcouldbecomparedagainst
theoriginal.Itwouldcertainlybemoredifficultforthemanin
themiddletoemulatethevoicesoftheparticipantsthantheir
signaling(apracticethatwasusedwiththeClipperchipbased
securetelephone).
TheS/MIMEmechanismallowsUAstosendencryptedrequestswithout
preambleiftheypossessacertificateforthedestinationaddress
ofrecordontheirkeyring.However,itispossiblethatany
particulardeviceregisteredforanaddressofrecordwillnothold
thecertificatethathasbeenpreviouslyemployedbythedevice's
currentuser,andthatitwillthereforebeunabletoprocessan
encryptedrequestproperly,whichcouldleadtosomeavoidableerror
signaling.Thisisespeciallylikelywhenanencryptedrequestis
forked.
ThekeysassociatedwithS/MIMEaremostusefulwhenassociatedwith
aparticularuser(anaddressofrecord)ratherthanadevice(aUA).
Whenusersmovebetweendevices,itmaybedifficulttotransport
privatekeyssecurelybetweenUAshowsuchkeysmightbeacquiredby
adeviceisoutsidethescopeofthisdocument.
Another,moreprosaicdifficultywiththeS/MIMEmechanismisthatit
canresultinverylargemessages,especiallywhentheSIPtunneling
mechanismdescribedinSection23.4isused.Forthatreason,itis
RECOMMENDEDthatTCPshouldbeusedasatransportprotocolwhen
S/MIMEtunnelingisemployed.
26.4.3TLS
ThemostcommonlyvoicedconcernaboutTLSisthatitcannotrunover
UDPTLSrequiresaconnectionorientedunderlyingtransport
protocol,whichforthepurposesofthisdocumentmeansTCP.
Itmayalsobearduousforalocaloutboundproxyserverand/or
registrartomaintainmanysimultaneouslonglivedTLSconnections
withnumerousUAs.Thisintroducessomevalidscalabilityconcerns,
especiallyforintensiveciphersuites.Maintainingredundancyof
longlivedTLSconnections,especiallywhenaUAissolely
responsiblefortheirestablishment,couldalsobecumbersome.
TLSonlyallowsSIPentitiestoauthenticateserverstowhichthey
areadjacentTLSoffersstrictlyhopbyhopsecurity.NeitherTLS,
noranyothermechanismspecifiedinthisdocument,allowsclientsto
authenticateproxyserverstowhomtheycannotformadirectTCP
connection.
26.4.4SIPSURIs
ActuallyusingTLSoneverysegmentofarequestpathentailsthat
theterminatingUASmustbereachableoverTLS(perhapsregistering
withaSIPSURIasacontactaddress).Thisisthepreferreduseof
SIPS.Manyvalidarchitectures,however,useTLStosecurepartof
therequestpath,butrelyonsomeothermechanismforthefinalhop
toaUAS,forexample.ThusSIPScannotguaranteethatTLSusage
willbetrulyendtoend.NotethatsincemanyUAswillnotaccept
incomingTLSconnections,eventhoseUAsthatdosupportTLSmaybe
requiredtomaintainpersistentTLSconnectionsasdescribedinthe
TLSlimitationssectionaboveinordertoreceiverequestsoverTLS
asaUAS.
LocationservicesarenotrequiredtoprovideaSIPSbindingfora
SIPSRequestURI.Althoughlocationservicesarecommonlypopulated
byuserregistrations(asdescribedinSection10.2.1),variousother
protocolsandinterfacescouldconceivablysupplycontactaddresses
foranAOR,andthesetoolsarefreetomapSIPSURIstoSIPURIsas
appropriate.Whenqueriedforbindings,alocationservicereturns
itscontactaddresseswithoutregardforwhetheritreceiveda
requestwithaSIPSRequestURI.Ifaredirectserverisaccessing
thelocationservice,itisuptotheentitythatprocessesthe
Contactheaderfieldofaredirectiontodeterminetheproprietyof
thecontactaddresses.
EnsuringthatTLSwillbeusedforalloftherequestsegmentsupto
thetargetdomainissomewhatcomplex.Itispossiblethat
cryptographicallyauthenticatedproxyserversalongthewaythatare
noncompliantorcompromisedmaychoosetodisregardtheforwarding
rulesassociatedwithSIPS(andthegeneralforwardingrulesin
Section16.6).Suchmaliciousintermediariescould,forexample,
retargetarequestfromaSIPSURItoaSIPURIinanattemptto
downgradesecurity.
Alternatively,anintermediarymightlegitimatelyretargetarequest
fromaSIPtoaSIPSURI.RecipientsofarequestwhoseRequestURI
usestheSIPSURIschemethuscannotassumeonthebasisofthe
RequestURIalonethatSIPSwasusedfortheentirerequestpath
(fromtheclientonwards).
Toaddresstheseconcerns,itisRECOMMENDEDthatrecipientsofa
requestwhoseRequestURIcontainsaSIPorSIPSURIinspecttheTo
headerfieldvaluetoseeifitcontainsaSIPSURI(thoughnotethat
itdoesnotconstituteabreachofsecurityifthisURIhasthesame
schemebutisnotequivalenttotheURIintheToheaderfield).
AlthoughclientsmaychoosetopopulatetheRequestURIandToheader
fieldofarequestdifferently,whenSIPSisusedthisdisparity
couldbeinterpretedasapossiblesecurityviolation,andthe
requestcouldconsequentlyberejectedbyitsrecipient.Recipients
MAYalsoinspecttheViaheaderchaininordertodoublecheck
whetherornotTLSwasusedfortheentirerequestpathuntilthe
localadministrativedomainwasreached.S/MIMEmayalsobeusedby
theoriginatingUACtohelpensurethattheoriginalformoftheTo
headerfieldiscarriedendtoend.
IftheUAShasreasontobelievethattheschemeoftheRequestURI
hasbeenimproperlymodifiedintransit,theUASHOULDnotifyits
userofapotentialsecuritybreach.
Asafurthermeasuretopreventdowngradeattacks,entitiesthat
acceptonlySIPSrequestsMAYalsorefuseconnectionsoninsecure
ports.
EnduserswillundoubtedlydiscernthedifferencebetweenSIPSand
SIPURIs,andtheymaymanuallyedittheminresponsetostimuli.
Thiscaneitherbenefitordegradesecurity.Forexample,ifan
attackercorruptsaDNScache,insertingafakerecordsetthat
effectivelyremovesallSIPSrecordsforaproxyserver,thenany
SIPSrequeststhattraversethisproxyservermayfail.Whenauser,
however,seesthatrepeatedcallstoaSIPSAORarefailing,they
couldonsomedevicesmanuallyconverttheschemefromSIPStoSIP
andretry.Ofcourse,therearesomesafeguardsagainstthis(ifthe
destinationUAistrulyparanoiditcouldrefuseallnonSIPS
requests),butitisalimitationworthnoting.Onthebrightside,
usersmightalsodivinethat'SIPS'wouldbevalidevenwhentheyare
presentedonlywithaSIPURI.
26.5Privacy
SIPmessagesfrequentlycontainsensitiveinformationabouttheir
sendersnotjustwhattheyhavetosay,butwithwhomthey
communicate,whentheycommunicateandforhowlong,andfromwhere
theyparticipateinsessions.Manyapplicationsandtheirusers
requirethatthissortofprivateinformationbehiddenfromany
partiesthatdonotneedtoknowit.
Notethattherearealsolessdirectwaysinwhichprivate
informationcanbedivulged.Ifauserorservicechoosestobe
reachableatanaddressthatisguessablefromtheperson'snameand
organizationalaffiliation(whichdescribesmostaddressesof
record),thetraditionalmethodofensuringprivacybyhavingan
unlisted"phonenumber"iscompromised.Auserlocationservicecan
infringeontheprivacyoftherecipientofasessioninvitationby
divulgingtheirspecificwhereaboutstothecalleranimplementation
consequentlySHOULDbeabletorestrict,onaperuserbasis,what
kindoflocationandavailabilityinformationisgivenouttocertain
classesofcallers.Thisisawholeclassofproblemthatis
expectedtobestudiedfurtherinongoingSIPwork.
Insomecases,usersmaywanttoconcealpersonalinformationin
headerfieldsthatconveyidentity.Thiscanapplynotonlytothe
Fromandrelatedheadersrepresentingtheoriginatoroftherequest,
butalsotheToitmaynotbeappropriatetoconveytothefinal
destinationaspeeddialingnickname,oranunexpandedidentifierfor
agroupoftargets,eitherofwhichwouldberemovedfromthe
RequestURIastherequestisrouted,butnotchangedintheTo
headerfieldifthetwowereinitiallyidentical.ThusitMAYbe
desirableforprivacyreasonstocreateaToheaderfieldthat
differsfromtheRequestURI.
27IANAConsiderations
Allmethodnames,headerfieldnames,statuscodes,andoptiontags
usedinSIPapplicationsareregisteredwithIANAthrough
instructionsinanIANAConsiderationssectioninanRFC.
ThespecificationinstructstheIANAtocreatefournewsub
registriesunderhttp://www.iana.org/assignments/sipparameters:
OptionTags,WarningCodes(warncodes),MethodsandResponseCodes,
addedtothesubregistryofHeaderFieldsthatisalreadypresent
there.
27.1OptionTags
ThisspecificationestablishestheOptionTagssubregistryunder
http://www.iana.org/assignments/sipparameters.
OptiontagsareusedinheaderfieldssuchasRequire,Supported,
ProxyRequire,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.2WarnCodes
ThisspecificationestablishestheWarncodessubregistryunder
http://www.iana.org/assignments/sipparametersandinitiatesits
populationwiththewarncodeslistedinSection20.43.Additional
warncodesareregisteredbyRFCpublication.
Thedescriptivetextforthetableofwarncodesis:
Warningcodesprovideinformationsupplementaltothestatuscodein
SIPresponsemessageswhenthefailureofthetransactionresults
fromaSessionDescriptionProtocol(SDP)(RFC2327[1])problem.
The"warncode"consistsofthreedigits.Afirstdigitof"3"
indicateswarningsspecifictoSIP.Untilafuturespecification
describesusesofwarncodesotherthan3xx,only3xxwarncodesmay
beregistered.
Warnings300through329arereservedforindicatingproblemswith
keywordsinthesessiondescription,330through339arewarnings
relatedtobasicnetworkservicesrequestedinthesession
description,370through379arewarningsrelatedtoquantitativeQoS
parametersrequestedinthesessiondescription,and390through399
aremiscellaneouswarningsthatdonotfallintooneoftheabove
categories.
27.3HeaderFieldNames
ThisobsoletestheIANAinstructionsabouttheheadersubregistry
underhttp://www.iana.org/assignments/sipparameters.
ThefollowinginformationneedstobeprovidedinanRFCpublication
inordertoregisteranewheaderfieldname:
oTheRFCnumberinwhichtheheaderisregistered
othenameoftheheaderfieldbeingregistered
oacompactformversionforthatheaderfield,ifoneis
defined
SomecommonandwidelyusedheaderfieldsMAYbeassignedoneletter
compactforms(Section7.3.3).Compactformscanonlybeassigned
afterSIPworkinggroupreview,followedbyRFCpublication.
27.4MethodandResponseCodes
ThisspecificationestablishestheMethodandResponseCodesub
registriesunderhttp://www.iana.org/assignments/sipparametersand
initiatestheirpopulationasfollows.TheinitialMethodstableis:
INVITE[RFC3261]
ACK[RFC3261]
BYE[RFC3261]
CANCEL[RFC3261]
REGISTER[RFC3261]
OPTIONS[RFC3261]
INFO[RFC2976]
TheresponsecodetableisinitiallypopulatedfromSection21,the
portionslabeledInformational,Success,Redirection,ClientError,
ServerError,andGlobalFailure.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
endtoendsecuritypurposes.Thismediatypeisdefinedbythe
followinginformation:
Mediatypename:message
Mediasubtypename:sip
Requiredparameters:none
Optionalparameters:version
version:TheSIPVersionnumberoftheenclosedmessage(e.g.,
"2.0").Ifnotpresent,theversiondefaultsto"2.0".
Encodingscheme:SIPmessagesconsistofan8bitheader
optionallyfollowedbyabinaryMIMEdataobject.Assuch,SIP
messagesmustbetreatedasbinary.Undernormalcircumstances
SIPmessagesaretransportedoverbinarycapabletransports,no
specialencodingsareneeded.
Securityconsiderations:seebelow
Motivationandexamplesofthisusageasasecuritymechanism
inconcertwithS/MIMEaregivenin23.4.
27.6NewContentDispositionParameterRegistrations
ThisdocumentalsoregistersfournewContentDispositionheader
"dispositiontypes":alert,icon,sessionandrender.Theauthors
requestthatthesevaluesberecordedintheIANAregistryfor
ContentDispositions.
Descriptionsofthese"dispositiontypes",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.
oSIPURLBNFwasmademoregeneral,allowingagreatersetof
charactersintheuserpart.Furthermore,comparisonruleswere
simplifiedtobeprimarilycaseinsensitive,anddetailedhandling
ofcomparisoninthepresenceofparameterswasdescribed.The
mostsubstantialchangeisthataURIwithaparameterwiththe
defaultvaluedoesnotmatchaURIwithoutthatparameter.
oRemovedViahiding.Ithadserioustrustissues,sinceitrelied
onthenexthoptoperformtheobfuscationprocess.Instead,Via
hidingcanbedoneasalocalimplementationchoiceinstateful
proxies,andthusisnolongerdocumented.
oInRFC2543,CANCELandINVITEtransactionswereintermingled.
Theyareseparatednow.WhenausersendsanINVITEandthena
CANCEL,theINVITEtransactionstillterminatesnormally.AUAS
needstorespondtotheoriginalINVITErequestwitha487
response.
oSimilarly,CANCELandBYEtransactionswereintermingledRFC2543
allowedtheUASnottosendaresponsetoINVITEwhenaBYEwas
received.Thatisdisallowedhere.TheoriginalINVITEneedsa
response.
oInRFC2543,UAsneededtosupportonlyUDP.InthisRFC,UAs
needtosupportbothUDPandTCP.
oInRFC2543,aforkingproxyonlypasseduponechallengefrom
downstreamelementsintheeventofmultiplechallenges.Inthis
RFC,proxiesaresupposedtocollectallchallengesandplacethem
intotheforwardedresponse.
oInDigestcredentials,theURIneedstobequotedthisisunclear
fromRFC2617andRFC2069whicharebothinconsistentonit.
oSDPprocessinghasbeensplitoffintoaseparatespecification
[13],andmorefullyspecifiedasaformaloffer/answerexchange
processthatiseffectivelytunneledthroughSIP.SDPisallowed
inINVITE/200or200/ACKforbaselineSIPimplementationsRFC
2543alludedtotheabilitytouseitinINVITE,200,andACKina
singletransaction,butthiswasnotwellspecified.Morecomplex
SDPusagesareallowedinextensions.
oAddedfullsupportforIPv6inURIsandintheViaheaderfield.
SupportforIPv6inViahasrequiredthatitsheaderfield
parametersallowthesquarebracketandcoloncharacters.These
characterswerepreviouslynotpermitted.Intheory,thiscould
causeinteropproblemswitholderimplementations.However,we
haveobservedthatmostimplementationsacceptanynoncontrol
ASCIIcharacterintheseparameters.
oDNSSRVprocedureisnowdocumentedinaseparatespecification
[4].ThisprocedureusesbothSRVandNAPTRresourcerecordsand
nolongercombinesdatafromacrossSRVrecordsasdescribedin
RFC2543.
oLoopdetectionhasbeenmadeoptional,supplantedbyamandatory
usageofMaxForwards.TheloopdetectionprocedureinRFC2543
hadaseriousbugwhichwouldreport"spirals"asanerror
conditionwhenitwasnot.Theoptionalloopdetectionprocedure
ismorefullyandcorrectlyspecifiedhere.
oUsageoftagsisnowmandatory(theywereoptionalinRFC2543),
astheyarenowthefundamentalbuildingblocksofdialog
identification.
oAddedtheSupportedheaderfield,allowingforclientstoindicate
whatextensionsaresupportedtoaserver,whichcanapplythose
extensionstotheresponse,andindicatetheirusagewitha
Requireintheresponse.
oExtensionparametersweremissingfromtheBNFforseveralheader
fields,andtheyhavebeenadded.
oHandlingofRouteandRecordRouteconstructionwasvery
underspecifiedinRFC2543,andalsonottherightapproach.It
hasbeensubstantiallyreworkedinthisspecification(andmade
vastlysimpler),andthisisarguablythelargestchange.
Backwardscompatibilityisstillprovidedfordeploymentsthatdo
notuse"preloadedroutes",wheretheinitialrequesthasaset
ofRouteheaderfieldvaluesobtainedinsomewayoutsideof
RecordRoute.Inthosesituations,thenewmechanismisnot
interoperable.
oInRFC2543,linesinamessagecouldbeterminatedwithCR,LF,
orCRLF.ThisspecificationonlyallowsCRLF.
oUsageofRouteinCANCELandACKwasnotwelldefinedinRFC2543.
ItisnowwellspecifiedifarequesthadaRouteheaderfield,
itsCANCELorACKforanon2xxresponsetotherequestneedto
carrythesameRouteheaderfieldvalues.ACKsfor2xxresponses
usetheRoutevalueslearnedfromtheRecordRouteofthe2xx
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.ItisallowedfornonINVITErequests,disallowed
forINVITE.
oPGPwasremoved.Itwasnotsufficientlyspecified,andnot
compatiblewiththemorecompletePGPMIME.Itwasreplacedwith
S/MIME.
oAddedthe"sips"URIschemeforendtoendTLS.Thisschemeis
notbackwardscompatiblewithRFC2543.Existingelementsthat
receivearequestwithaSIPSURIschemeintheRequestURIwill
likelyrejecttherequest.Thisisactuallyafeatureitensures
thatacalltoaSIPSURIisonlydeliveredifallpathhopscan
besecured.
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.
oProxiesnolongerforwarda6xximmediatelyonreceivingit.
Instead,theyCANCELpendingbranchesimmediately.Thisavoidsa
potentialraceconditionthatwouldresultinaUACgettinga6xx
followedbya2xx.Inallcasesexceptthisracecondition,the
resultwillbethesamethe6xxisforwardedupstream.
oRFC2543didnotaddresstheproblemofrequestmerging.This
occurswhenarequestforksataproxyandlaterrejoinsatan
element.HandlingofmergingisdoneonlyataUA,andprocedures
aredefinedforrejectingallbutthefirstrequest.
28.2MinorFunctionalChanges
oAddedtheAlertInfo,ErrorInfo,andCallInfoheaderfieldsfor
optionalcontentpresentationtousers.
oAddedtheContentLanguage,ContentDispositionandMIMEVersion
headerfields.
oAddeda"glarehandling"mechanismtodealwiththecasewhere
bothpartiessendeachotherareINVITEsimultaneously.Ituses
thenew491(RequestPending)errorcode.
oAddedtheInReplyToandReplyToheaderfieldsforsupporting
thereturnofmissedcallsormessagesatalatertime.
oAddedTLSandSCTPasvalidSIPtransports.
oTherewereavarietyofmechanismsdescribedforhandlingfailures
atanytimeduringacallthosearenowgenerallyunified.BYE
issenttoterminate.
oRFC2543mandatedretransmissionofINVITEresponsesoverTCP,but
noteditwasreallyonlyneededfor2xx.Thatwasanartifactof
insufficientprotocollayering.Withamorecoherenttransaction
layerdefinedhere,thatisnolongerneeded.Only2xxresponses
toINVITEsareretransmittedoverTCP.
oClientandservertransactionmachinesarenowdrivenbasedon
timeoutsratherthanretransmitcounts.Thisallowsthestate
machinestobeproperlyspecifiedforTCPandUDP.
oTheDateheaderfieldisusedinREGISTERresponsestoprovidea
simplemeansforautoconfigurationofdatesinuseragents.
oAllowedaregistrartorejectregistrationswithexpirationsthat
aretooshortinduration.Definedthe423responsecodeandthe
MinExpiresforthispurpose.
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]BernersLee,T.,Fielding,R.andL.Masinter,"UniformResource
Identifiers(URI):GenericSyntax",RFC2396,August1998.
[6]Chown,P.,"AdvancedEncryptionStandard(AES)Ciphersuitesfor
TransportLayerSecurity(TLS)",RFC3268,June2002.
[7]Yergeau,F.,"UTF8,atransformationformatofISO10646",RFC
2279,January1998.
[8]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,
Leach,P.andT.BernersLee,"HypertextTransferProtocol
HTTP/1.1",RFC2616,June1999.
[9]VahaSipila,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.
[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.,HallamBaker,P.,Hostetler,J.,Lawrence,S.,
Leach,P.,Luotonen,A.andL.Stewart,"HTTPauthentication:
BasicandDigestAccessAuthentication",RFC2617,June1999.
[18]Troost,R.,Dorner,S.andK.Moore,"CommunicatingPresentation
InformationinInternetMessages:TheContentDispositionHeader
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.,"RequirementsforInternetHostsApplicationand
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.4452,June1995.
[28]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,
"RTP:ATransportProtocolforRealTimeApplications",RFC
1889,January1996.
[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'sThesisCSTR9618,Department
ofComputerScience,CaliforniaInstituteofTechnology,
Pasadena,California,Aug.1996.
[34]Donovan,S.,"TheSIPINFOMethod",RFC2976,October2000.
[35]Rivest,R.,"TheMD5MessageDigestAlgorithm",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.,HallamBaker,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
packetswitchedteleconferencingsystem,"Journalof
Internetworking:ResearchandExperience,Vol.4,pp.99120,
June1993.ISIreprintseriesISI/RS93359.
[42]H.Schulzrinne,"Personalmobilityformultimediaservicesin
theInternet,"inEuropeanWorkshoponInteractiveDistributed
MultimediaSystemsandServices(IDMS),(Berlin,Germany),Mar.
1996.
[43]Floyd,S.,"CongestionControlPrinciples",RFC2914,September
2000.
ATableofTimerValues
Table4summarizesthemeaninganddefaultsofthevarioustimers
usedbythisspecification.
TimerValueSectionMeaning

T1500msdefaultSection17.1.1.1RTTEstimate
T24sSection17.1.2.2Themaximumretransmit
intervalfornonINVITE
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.2nonINVITErequest
retransmitinterval,
UDPonly
TimerF64*T1Section17.1.2.2nonINVITEtransaction
timeouttimer
TimerGinitiallyT1Section17.2.1INVITEresponse
retransmitinterval
TimerH64*T1Section17.2.1Waittimefor
ACKreceipt
TimerIT4forUDPSection17.2.1Waittimefor
0sforTCP/SCTPACKretransmits
TimerJ64*T1forUDPSection17.2.2Waittimefor
0sforTCP/SCTPnonINVITErequest
retransmits
TimerKT4forUDPSection17.1.2.2Waittimefor
0sforTCP/SCTPresponseretransmits
Table4:Summaryoftimers
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].
Authors'Addresses
Authorsaddressesarelistedalphabeticallyfortheeditors,the
writers,andthentheoriginalauthorsofRFC2543.Alllisted
authorsactivelycontributedlargeamountsoftexttothisdocument.
JonathanRosenberg
dynamicsoft
72EagleRockAve
EastHanover,NJ07936
USA
EMail:jdrosen@dynamicsoft.com
HenningSchulzrinne
Dept.ofComputerScience
ColumbiaUniversity
1214AmsterdamAvenue
NewYork,NY10027
USA
EMail:schulzrinne@cs.columbia.edu
GonzaloCamarillo
Ericsson
AdvancedSignallingResearchLab.
FIN02420Jorvas
Finland
EMail:Gonzalo.Camarillo@ericsson.com
AlanJohnston
WorldCom
100South4thStreet
St.Louis,MO63102
USA
EMail:alan.johnston@wcom.com
JonPeterson
NeuStar,Inc
1800SutterStreet,Suite570
Concord,CA94520
USA
EMail:jon.peterson@neustar.com
RobertSparks
dynamicsoft,Inc.
5100TennysonParkway
Suite1200
Plano,Texas75024
USA
EMail:rsparks@dynamicsoft.com
MarkHandley
InternationalComputerScienceInstitute
1947CenterSt,Suite600
Berkeley,CA94704
USA
EMail:mjh@icir.org
EveSchooler
AT&TLabsResearch
75WillowRoad
MenloPark,CA94025
USA
EMail:schooler@research.att.com
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.

SIP Protocol Rfc3261

Загружено:

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

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

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

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

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

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

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

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

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

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

SIP Protocol Rfc3261

Загружено:

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

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

1/5/2015 https://www.ietf.org/rfc/rfc3261.

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