11 Querying for Capabilities
12.2 Requests within a Dialog
1924
Once a dialog has been established between two UAs, either of themMAYinitiate new transactions as needed
1925
within the dialog. The UA sending the request will take the UAC role for the transaction. The UA receiving
1926
the request will take the UAS role. Note that these may be different roles than the UAs held during the
1927
transaction that established the dialog.
1928
Requests within a dialog MAYcontainRecord-Routeand Contactheader fields. However, these
re-1929
quests do not cause the dialog’s route set to be modified, although they may modify the remote target URI.
1930
Specifically, requests that are not target refresh requests do not modify the dialog’s remote target URI, and
1931
requests that are target refresh requests do. For dialogs that have been established with anINVITE, the only
1932
target refresh request defined is re-INVITE(see Section 14). Other extensions may define different target
1933
refresh requests for dialogs established in other ways.
1934
Note that anACKis NOT a target refresh request.
1935
Target refresh requests only update the dialog’s remote target URI, and not the route set formed from
Record-1936
Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant
1937
systems.
1938
12.2.1 UAC Behavior
1939
12.2.1.1 Generating the Request A request within a dialog is constructed by using many of the
com-1940
ponents of the state stored as part of the dialog.
1941
The URI in theTo field of the request MUSTbe set to the remote URI from the dialog state. The tag
1942
in theToheader field of the requestMUSTbe set to the remote tag of the dialog ID. TheFromURI of the
1943
requestMUSTbe set to the local URI from the dialog state. The tag in theFromheader field of the request
1944
MUSTbe set to the local tag of the dialog ID. If the value of the remote or local tags is null, the tag parameter
1945
MUSTbe omitted from theToorFromheader fields, respectively.
1946
Usage of the URI from theToandFromfields in the original request within subsequent requests is done for
1947
backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only
1948
the tags are used for dialog identification. It is expected that mandatory reflection of the originalToandFromURI
1949
in mid-dialog requests will be deprecated in a subsequent revision of this specification.
1950
The Call-IDof the request MUST be set to theCall-IDof the dialog. Requests within a dialog MUST
1951
contain strictly monotonically increasing and contiguous CSeqsequence numbers (increasing-by-one) in
1952
each direction (exceptingACKandCANCELof course, whose numbers equal the requests being
acknowl-1953
edged or cancelled). Therefore, if the local sequence number is not empty, the value of the local sequence
1954
number MUSTbe incremented by one, and this value MUST be placed into theCSeqheader field. If the
1955
local sequence number is empty, an initial value MUSTbe chosen using the guidelines of Section 8.1.1.5.
1956
The method field in theCSeqheader field valueMUSTmatch the method of the request.
1957
With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years
1958
before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within
1959
the same call will not wrap around. A non-zero initial value allows clients to use a time-based initial sequence
1960
number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial
1961
sequence number.
1962
The UAC uses the remote target and route set to build theRequest-URIandRouteheader field of the
1963
request.
1964
If the route set is empty, the UACMUSTplace the remote target URI into theRequest-URI. The UAC
1965
MUST NOTadd aRouteheader field to the request.
1966
If the route set is not empty, and the first URI in the route set contains the lr parameter (see
Sec-1967
tion 19.1.1), the UACMUSTplace the remote target URI into theRequest-URIandMUSTinclude aRoute
1968
header field containing the route set values in order, including all parameters.
1969
If the route set is not empty, and its first URI does not contain thelrparameter, the UAC MUSTplace
1970
the first URI from the route set into theRequest-URI, stripping any parameters that are not allowed in a
1971
Request-URI. The UACMUSTadd aRouteheader field containing the remainder of the route set values
1972
in order, including all parameters. The UACMUSTthen place the remote target URI into theRouteheader
1973
field as the last value.
1974
For example, if the remote target is sip:user@remoteua and the route set contains
1975
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
1976
The request will be formed with the followingRequest-URIandRouteheader field:
1977
METHOD sip:proxy1
1978
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
1979
If the first URI of the route set does not contain thelrparameter, the proxy indicated does not understand the
1980
routing mechanisms described in this document and will act as specified in RFC 2543, replacing theRequest-URI
1981
with the firstRouteheader field value it receives while forwarding the message. Placing theRequest-URIat the
1982
end of theRouteheader field preserves the information in thatRequest-URIacross the strict router (it will be
1983
returned to theRequest-URIwhen the request reaches a loose-router).
1984
A UACSHOULDinclude aContactheader field in any target refresh requests within a dialog, and unless
1985
there is a need to change it, the URISHOULDbe the same as used in previous requests within the dialog. If
1986
the “secure” flag is true, that URIMUSTbe a SIPS URI. As discussed in Section 12.2.2, aContactheader
1987
field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact
1988
address, should its address change during the duration of the dialog.
1989
However, requests that are not target refresh requests do not affect the remote target URI for the dialog.
1990
The rest of the request is formed as described in Section 8.1.1.
1991
Once the request has been constructed, the address of the server is computed and the request is sent,
1992
using the same procedures for requests outside of a dialog (Section 8.1.2).
1993
The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the
1994
topmostRouteheader field value or theRequest-URIif noRouteheader field is present. Subject to certain
1995
restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented
1996
in the route set).
1997
12.2.1.2 Processing the Responses The UAC will receive responses to the request from the transaction
1998
layer. If the client transaction returns a timeout this is treated as a 408 (Request Timeout) response.
1999
The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if
2000
the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4.
2001
Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the
2002
Routeheader of the request.
2003
When a UAC receives a 2xx response to a target refresh request, it MUSTreplace the dialog’s remote
2004
target URI with the URI from theContactheader field in that response, if present.
2005
If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request
2006
Timeout), the UACSHOULDterminate the dialog. A UACSHOULDalso terminate a dialog if no response
2007
at all is received for the request (the client transaction would inform the TU about the timeout.)
2008
ForINVITEinitiated dialogs, terminating the dialog consists of sending aBYE.
2009
12.2.2 UAS Behavior
2010
Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the
2011
UAS, all the state changes associated with it are performed. If the request is rejected, none of the state
2012
changes is performed.
2013
Note that some requests such asINVITEs affect several pieces of state.
2014
The UAS will receive the request from the transaction layer. If the request has a tag in theToheader
2015
field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing
2016
dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same
2017
processing rules for requests outside of a dialog, discussed in Section 8.2.
2018
If the request has a tag in theTo header field, but the dialog identifier does not match any existing
di-2019
alogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly
2020
failed) UAS (the UASs can construct theTo tags so that a UAS can identify that the tag was for a UAS
2021
for which it is providing recovery). Another possibility is that the incoming request has been simply
mis-2022
routed. Based on theTo tag, the UASMAY either accept or reject the request. Accepting the request for
2023
acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to
2024
support this capability must take into consideration some issues such as choosing monotonically increasing
2025
CSeqsequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP
2026
timestamps and sequence numbers.
2027
If the UAS wishes to reject the request, because it does not wish to recreate the dialog, itMUSTrespond
2028
to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction.
2029
Requests that do not change in any way the state of a dialog may be received within a dialog (for
2030
example, anOPTIONSrequest). They are processed as if they had been received outside the dialog.
2031
If the remote sequence number is empty, itMUSTbe set to the value of the sequence number in theCSeq
2032
header field value in the request. If the remote sequence number was not empty, but the sequence number of
2033
the request is lower than the remote sequence number, the request is out of order andMUSTbe rejected with
2034
a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence
2035
number of the request is greater than the remote sequence number, the request is in order. It is possible for
2036
theCSeqsequence number to be higher than the remote sequence number by more than one. This is not
2037
an error condition, and a UASSHOULDbe prepared to receive and process requests withCSeqvalues more
2038
than one higher than the previous received request. The UASMUSTthen set the remote sequence number to
2039
the value of the sequence number in theCSeqheader field value in the request.
2040
If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The
2041
resubmitted request will have a newCSeqnumber. The UAS will never see the first request, and thus, it will notice
2042
a gap in theCSeqnumber space. Such a gap does not represent any error condition.
2043
When a UAS receives a target refresh request, it MUSTreplace the dialog’s remote target URI with the
2044
URI from theContactheader field in that request, if present.
2045