SIP Clients and Servers |
61 |
SIP. This solves the problem of how long to store state information in cases where a BYE request is lost or misdirected, or in other security cases described in later sections. The details of this implementation are described in Section 6.2.34.
3.5.2Redirect Servers
A redirect server was introduced in Figure 2.6 as a type of SIP server that responds to, but does not forward, requests. Like a proxy server, a redirect server uses a database or location service to lookup a user. The location information, however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes the transaction. Figure 3.5 shows a call flow that is very similar to the example in Figure 3.2, except the server uses redirection instead of proxying to assist Schroedinger in locating Heisenberg.
The INVITE from Figure 3.5 contains:
INVITE sip:werner.heisenberg@munich.de SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060 ;branch=z9hG4bK54532 Max-Forwards: 70
To: Heisenberg <sip:werner.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@wave.org>;tag=4313413 Call-ID: 734224912341371927319032
CSeq: 1 INVITE
Figure 3.5 Example with redirect server.
62 SIP: Understanding the Session Initiation Protocol
Subject: Where are you exactly?
Contact: <sip:schroed5244@pc33.wave.org>
Content-Type: application/sdp
Content-Length: 150
v=0
o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=-
t=0 0
c=IN IP4 100.101.102.103 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
The redirection response to the INVITE is sent by the redirect server:
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK54532
To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=052500 From: E. Schroedinger <sip:schroed5244@wave.org>;tag=4313413 Call-ID: 734224912341371927319032
CSeq: 1 INVITE
Contact: sip:werner.heisenberg@200.201.202.203 Content-Length: 0
Schroedinger acknowledges the response:
ACK sip:werner.heisenberg@munich.de SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK54532 Max-Forwards: 70
To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=052500 From: E. Schroedinger <sip:schroed5244@wave.org>;tag=4313413 Call-ID: 734224912341371927319032
CSeq: 1 ACK Content-Length: 0
Notice that the ACK request reuses the same branch ID as the INVITE and the 302 response. This is because an ACK to a non-2xx final response is considered to be part of the same transaction as the INVITE. Only an ACK sent in response to a 200 OK is considered a separate transaction with a unique branch ID. Also, an ACK to a non-2xx final response is a hop-by-hop response, not an end-to-end response as discussed in Section 3.6.
This exchange completes this call attempt, so a new INVITE is generated with a new Call-ID and sent directly to the location obtained from the Contact header field in the 302 response from the redirect server.
INVITE sip:werner.heisenberg@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK92313 Max-Forwards: 70
To: Heisenberg <sip:werner.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@wave.org>;tag=13473 Call-ID: 54-67-45-23-13
CSeq: 1 INVITE
Subject: Where are you exactly?
SIP Clients and Servers |
63 |
Contact: <sip:schroed5244@pc33.wave.org>
Content-Type: application/sdp
Content-Length: 150
v=0
o=schroed5244 2890844526 2890844526 IN IP4 00.101.102.103
s=- t=0 0
c=IN IP4 100.101.102.103 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
The call then proceeds in the same way as Figure 3.2, with the messages being identical. Note that in Figure 3.5, a 180 Ringing response is not sent; instead, the 200 OK response is sent right away. Since 1xx informational responses are optional, this is a perfectly valid response by the UAS if Heisenberg responded to the alerting immediately and accepted the call. In the PSTN, this scenario is called fast answer.
3.5.3Registrar Servers
A SIP registrar server was introduced in the example of Figure 3.3. A registrar server, also known as a registration server, accepts SIP REGISTER requests; all other requests receive a 501 Not Implemented response. The contact information from the request is then made available to other SIP servers within the same administrative domain, such as proxies and redirect servers. In a registration request, the To header field contains the name of the resource being registered, and the Contact header fields contain the contact or device URIs. The registration server creates a temporary binding between the address of record (AOR) URI in the To and the device URI in the Contact header field.
Registration servers usually require the registering user agent to be authenticated, using the means described in Chapter 14, so that incoming calls cannot be hijacked by an unauthorized user. This could be accomplished by an unauthorized user registering someone else’s SIP URI to point to their own UA. Incoming calls to that URI would then ring the wrong UA. Depending on the header fields present, a REGISTER request can be used by a user agent to retrieve a list of current registrations, clear all registrations, or add a registration URI to the list. These types of requests are described in Section 4.1.2.
There are a number of ways in which a proxy may know to fork a request to a set of UAs. One way is through manual configuration, such as entering the information in a Web page or database. Another way is to have multiple registrations for the same AOR. If multiple UAs register against the same AOR, the proxy can fork an incoming request to all of them. The priority of multiple registrations is governed by the q-value included in the Contact header field. For contacts of the same priority, a proxy can fork the request to all of them at the