The ACK for a 2xx is constructed the same as any other request within the
dialog. The only exception is that it has the same Cseq as the INVITE. It
gets its own unique branch id. An ACK for a non-2xx final response will have
the same branch id as the original INVITE. All of these points are in the
text you cite.
cheers,
(-:bob
Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[EMAIL PROTECTED]
----- Original Message -----
From: "Boffelli Lorenzo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 05, 2002 8:31 PM
Subject: [Sip-implementors] Branch value in ACK for 2xx response.
Hi,
I can not find where is described how build an ACK for a 2xx response.
In an ACK message (in response to a 200 OK) into the Via header what is the
"branch" parameter value I have to use?
Have I to use a new branch value?
Have I to use the same value used into INVITE message?
I can not find this indication explained clearly into RFC3261.
I follow the "path" reported below.
Where I can find this indication?
Thanks
Lorenzo
----------------------------------------------------------------------------
----
--------------------------------
### In RFC 3261 (8.1.1.7 Via - page 39) you can find:
The branch parameter value MUST be unique across space and time for
all requests sent by the UA. The exceptions to this rule are CANCEL
and ACK for non-2xx responses. As discussed below, a CANCEL request
will have the same value of the branch parameter as the request it
cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx
response will also have the same branch ID as the INVITE whose
response it acknowledges.
### In RFC 3261 (17.1.1.3 Construction of the ACK Request pag 129 ) you can
find:
17.1.1.3 Construction of the ACK Request
This section specifies the construction of ACK requests sent within
the client transaction. A UAC core that generates an ACK for 2xx
MUST instead follow the rules described in Section 13.
### In RFC 3261 (13.2.2.4 2xx Responses pag 82 ) you can find:
13.2.2.4 2xx Responses
.........
The UAC core MUST generate an ACK request for each 2xx received from
the transaction layer. The header fields of the ACK are constructed
in the same way as for any request sent within a dialog (see Section
12) with the exception of the CSeq and the header fields related to
authentication.
### In RFC 3261 (12.2.1 2xx UAC Behavior pag 73 ) you can find:
12.2.1 UAC Behavior
12.2.1.1 Generating the Request
A request within a dialog is constructed by using many of the
components of the state stored as part of the dialog.
The URI in the To field of the request MUST be set to the remote URI
from the dialog state. The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID. The From URI of the
request MUST be set to the local URI from the dialog state. The tag
in the From header field of the request MUST be set to the local tag
of the dialog ID. If the value of the remote or local tags is null,
the tag parameter MUST be omitted from the To or From header fields,
respectively.
Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification.
The Call-ID of the request MUST be set to the Call-ID of the dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction (excepting ACK and CANCEL of course, whose numbers
equal the requests being acknowledged or cancelled). Therefore, if
the local sequence number is not empty, the value of the local
sequence number MUST be incremented by one, and this value MUST be
placed into the CSeq header field. If the local sequence number is
empty, an initial value MUST be chosen using the guidelines of
Section 8.1.1.5. The method field in the CSeq header field value
MUST match the method of the request.
With a length of 32 bits, a client could generate, within a single
call, one request a second for about 136 years before needing to
wrap around. The initial value of the sequence number is chosen
so that subsequent requests within the same call will not wrap
around. A non-zero initial value allows clients to use a time-
based initial sequence number. A client could, for example,
choose the 31 most significant bits of a 32-bit second clock as an
initial sequence number.
The UAC uses the remote target and route set to build the Request-URI
and Route header field of the request.
If the route set is empty, the UAC MUST place the remote target URI
into the Request-URI. The UAC MUST NOT add a Route header field to
the request.
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
parameters.
If the route set is not empty, and its first URI does not contain the
lr parameter, the UAC MUST place the first URI from the route set
into the Request-URI, stripping any parameters that are not allowed
in a Request-URI. The UAC MUST add a Route header field containing
the remainder of the route set values in order, including all
parameters. The UAC MUST then place the remote target URI into the
Route header field as the last value.
For example, if the remote target is sip:user@remoteua and the route
set contains:
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
The request will be formed with the following Request-URI and Route
header field:
METHOD sip:proxy1
Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
If the first URI of the route set does not contain the lr
parameter, the proxy indicated does not understand the routing
mechanisms described in this document and will act as specified in
RFC 2543, replacing the Request-URI with the first Route header
field value it receives while forwarding the message. Placing the
Request-URI at the end of the Route header field preserves the
information in that Request-URI across the strict router (it will
be returned to the Request-URI when the request reaches a loose-
router).
A UAC SHOULD include a Contact header field in any target refresh
requests within a dialog, and unless there is a need to change it,
the URI SHOULD be the same as used in previous requests within the
dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.
As discussed in Section 12.2.2, a Contact header field in a target
refresh request updates the remote target URI. This allows a UA to
provide a new contact address, should its address change during the
duration of the dialog.
However, requests that are not target refresh requests do not affect
the remote target URI for the dialog.
The rest of the request is formed as described in Section 8.1.1.
----------------------------------------------------------------------------
----
-----------------------
___________________________________________
Lorenzo Boffelli
STRE Senior Engineer
Allied Telesis K.K.
Head Office / 4F TOC Bldg, 7-22-17 Nishi-Gotanda,
Shinagawa-ku, Tokyo Japan, 141-8635
European R&D Center
Piazza Tirana, 24/4 b Phone: +39 02 41411237
20147 Milano Fax: +39 02 41411260
ITALY
Email: [EMAIL PROTECTED]
SIP url: sip:37@eurordvoipnet
___________________________________________
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
