16 Proxy Behavior
17.2 Server Transaction
17.2.3 Matching Requests to Server Transactions
3499
When a request is received from the network by the server, it has to be matched to an existing transaction.
3500
This is accomplished in the following manner.
3501
|Request received |pass to TU V +−−−−−−−−−−−+
| | | Trying |−−−−−−−−−−−−−+
| | | +−−−−−−−−−−−+ |200−699 from TU | |send response |1xx from TU | |send response | | | Request V 1xx from TU | send response+−−−−−−−−−−−+send response|
+−−−−−−−−| |−−−−−−−−+ | | | Proceeding| | | +−−−−−−−>| |<−−−−−−−+ | +<−−−−−−−−−−−−−−| | | |Trnsprt Err +−−−−−−−−−−−+ | |Inform TU | | | | | | |200−699 from TU | | |send response | | Request V | | send response+−−−−−−−−−−−+ | | +−−−−−−−−| | | | | | Completed |−−−−−−−−−−−−−+
| +−−−−−−−>| | +<−−−−−−−−−−−−−−| | |Trnsprt Err +−−−−−−−−−−−+
|Inform TU | | |Timer J fires | |−
| | | V | +−−−−−−−−−−−+
| | | +−−−−−−−−−−−−−−>| Terminated|
| | +−−−−−−−−−−−+
The branch parameter in the topmost Viaheader field of the request is examined. If it is present and
3502
begins with the magic cookie “z9hG4bK”, the request was generated by a client transaction compliant to this
3503
specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The
3504
request matches a transaction if the branch parameter in the request is equal to the one in the topViaheader
3505
field of the request that created the transaction, thesent-by value in the topViaof the request is equal to
3506
the one in the request that created the transaction, and in the case of aCANCELrequest, the method of
3507
the request that created the transaction was alsoCANCEL. This matching rule applies to bothINVITEand
3508
non-INVITEtransactions alike.
3509
Thesent-byvalue is used as part of the matching process because there could be accidental or malicious
dupli-3510
cation of branch parameters from different clients.
3511
If the branch parameter in the topViaheader field is not present, or does not contain the magic cookie,
3512
the following procedures are used. These exist to handle backwards compatibility with RFC 2543 compliant
3513
implementations.
3514
TheINVITErequest matches a transaction if theRequest-URI,Totag,Fromtag,Call-ID,CSeq, and
3515
top Viaheader field match those of the INVITE request which created the transaction. In this case, the
3516
INVITEis a retransmission of the original one that created the transaction. The ACK request matches a
3517
transaction if theRequest-URI,Fromtag,Call-ID, CSeqnumber (not the method), and top Viaheader
3518
field match those of theINVITErequest which created the transaction, and theTotag of theACKmatches the
3519
Totag of the response sent by the server transaction. Matching is done based on the matching rules defined
3520
for each of those header fields. Inclusion of the tag in the Toheader field in the ACKmatching process
3521
helps disambiguate ACK for 2xx from ACK for other responses at a proxy, which may have forwarded
3522
both responses (This can occur in unusual conditions. Specifically, when a proxy forked a request, and then
3523
crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses
3524
upstream). AnACKrequest that matches anINVITEtransaction matched by a previousACKis considered
3525
a retransmission of that previousACK.
3526
For all other request methods, a request is matched to a transaction if theRequest-URI,Totag,From
3527
tag,Call-ID Cseq(including the method), and topViaheader field match those of the request that created
3528
the transaction. Matching is done based on the matching rules defined for each of those header fields. When
3529
a non-INVITErequest matches an existing transaction, it is a retransmission of the request that created that
3530
transaction.
3531
Because the matching rules include theRequest-URI, the server cannot match a response to a
transac-3532
tion. When the TU passes a response to the server transaction, it must pass it to the specific server transaction
3533
for which the response is targeted.
3534
17.2.4 Handling Transport Errors
3535
When the server transaction sends a response to the transport layer to be sent, the following procedures are
3536
followed if the transport layer indicates a failure.
3537
First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those
3538
should all fail, based on the definition of failure in [4], the server transactionSHOULDinform the TU that a
3539
failure has occurred, andSHOULDtransition to the terminated state.
3540
18 Transport
3541
The transport layer is responsible for the actual transmission of requests and responses over network
trans-3542
ports. This includes determination of the connection to use for a request or response in the case of
connection-3543
oriented transports.
3544
The transport layer is responsible for managing persistent connections for transport protocols like TCP
3545
and SCTP, or TLS over those, including ones opened to the transport layer. This includes connections
3546
opened by the client or server transports, so that connections are shared between client and server transport
3547
functions. These connections are indexed by the tuple formed from the address, port, and transport protocol
3548
at the far end of the connection. When a connection is opened by the transport layer, this index is set to the
3549
destination IP, port and transport. When the connection is accepted by the transport layer, this index is set to
3550
the source IP address, port number, and transport. Note that, because the source port is often ephemeral, but
3551
it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by
3552
the transport layer will frequently not be reused. The result is that two proxies in a “peering” relationship
3553
using a connection-oriented transport frequently will have two connections in use, one for transactions
3554
initiated in each direction.
3555
It isRECOMMENDEDthat connections be kept open for some implementation-defined duration after the
3556
last message was sent or received over that connection. This duration SHOULD at least equal the longest
3557
amount of time the element would need in order to bring a transaction from instantiation to the terminated
3558
state. This is to make it likely that transactions complete over the same connection on which they are
3559
initiated (for example, request, response, and in the case of INVITE,ACK for non-2xx responses). This
3560
usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, it could be larger in an
3561
element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example.
3562
All SIP elementsMUSTimplement UDP and TCP. SIP elementsMAYimplement other protocols.
3563
Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to
3564
handle larger messages, whichMUSTuse TCP, as discussed below. Thus, even if an element never sends large
3565
messages, it may receive one and needs to be able to handle them.
3566
18.1 Clients
3567