This method is used by a User Agent in order to perform the registration procedure. As we saw in Chapter 4, the registration procedure occurs between a UAC and a registrar. It allows the UA to associate its public identity, the so-called Address of Record (AOR), to its current location, called Contact Address, from which the IP address can be easily obtained. The database that contains the list of bindings is called Location Service.

The UAC builds a REGISTER request, and includes the following information:

The domain or address of the registrar server expressed as a SIP URI (e.g., sip: registrar.sea.com). It is included in the Request-URI element of the SIP message. The address or domain of the registrar may be preconfigured in the UA.

If the request is successful, the registrar will return a response with status code 200. The response will include a Contact header field that indicates the Contact Address stored in the Location Service.

Figure 6.3 shows the registration process. In this example, the Location Service is co-located with the registrar (as is usually the case).

Figure 6.3. 

As a result of the registration procedure, a binding is created in the Location Service. The binding created in the Location Service is a soft state that expires if it is not refreshed. The UA may suggest in the REGISTER request the value of the desired expiry timer by using the Expires header field. However, it is up to the registrar to decide the final value and communicate it back to the UA in the Expires header field of the response.

The UA can refresh the binding before it expires by sending a new REGISTER request. Likewise, the UA can also explicitly request that the binding be removed by sending a REGISTER request with the Expires header field set to 0. For instance, a user that no longer wants to receive incoming calls can request that the binding be removed.

The usual case is that the UA initiating the REGISTER request is the one that is required to be registered. However, there are cases where a UA may want to perform a registration procedure on behalf of another UA. This is called third-party registration. The From header in a REGISTER request indicates the identity (i.e., AOR) of the originator of the request. This may be the same as the identity in the To header (first-party registration), or it may be different (third-party registration).

The information in the Location Service is used whenever a call is made to a SIP user. In those cases, the called user’s associated SIP server will query the Location Service in order to derive the location of the destination endpoint needed to send him or her the session-invitation message.

A UAC generates an INVITE method in order to initiate a session with a UAS. The request will contain the public identity, as a SIP URI, of the user to which the request is addressed in a field called Request-URI. The request can go directly from UAC to UAS, or may traverse one or more proxies, which can then assist in the routing of the request.

Once the UAS has received the request, it may generate some provisional response to inform about the progress of the call. For example, it might generate a response with status code 180, indicating that the called party is being alerted. If the called party accepts the call, his or her UA will generate a 200 OK final response.

Alternatively, a UAS might respond directly with a final 200 OK response to a session-initiation request. That is usually the case where the session is established with a machine such as a Voice Mail System (VMS) or other. In those cases there is no point in performing the alerting.

The INVITE transaction is also used to exchange and agree on some fundamental session parameters between the calling UA and the called UA. For instance, in a voice or video communication, the calling party and the called party need to agree on the codecs to use. They also need to inform each other about the address (IP address, port) where they expect to receive the RTP (Real-time Transport Protocol) packets. Several mechanisms can be used to describe the sessions; it is usual to use the Session Description Protocol (SDP) for that purpose.

For instance, if Alice wanted to set up a voice call to John, she would include the following parameters in the SDP session descriptor:

This indicates to John’s UA that Alice wants to set up a voice communication using one of two codecs: Pulse Code Modulation or Adaptive Multirate. It also indicates the port in Alice’s PC to which packets flowing from John should be sent. This session descriptor is called the “SDP offer.” Please note that we have not described all the parameters in the SDP content, but only the most important ones; we are now focusing on letting the reader understand how the SIP methods work. In Chapter 9, SDP syntax and semantics will be described in detail.

In the 200 OK final response, John’s UA will include another session descriptor that represents his answer to the SDP offer. Let us assume that John does not have a codec for AMR, so his SDP answer might look like:

What this tells Alice is that John accepts the invitation, that he agrees to use a PCM codec, and that voice data should be sent to port 80000 in his PC at IP address 1.2.3.4.

Figure 6.4 shows an INVITE transaction that initiates a session between Alice and John.

Figure 6.4. 

Another interesting aspect of the INVITE transaction is that it creates a peer-to-peer SIP relationship between Peter and Alice that is referred to as a dialog. The SIP dialog represents an information context in which to interpret SIP messages. It basically facilitates sequencing of messages between the User Agents and proper routing of requests between both of them. Dialogs will be analyzed in Chapter 7.

An INVITE request can also be sent within an already-established dialog. In such case, it is normally referred to as a re-INVITE.^[1] A re-INVITE is typically used in order to modify the parameters of the session. In our previous example, Alice and John set up a voice session. Let us imagine that, in the middle of the session, Alice decides to add a video component so that John is able to see the nice cake she is preparing. In that case, Alice would send a new INVITE (i.e., a re-INVITE) within the same dialog that established the session, except that now the SDP includes an additional video component. The SDP would contain, among others, the following information:

Figure 6.5 depicts this situation.

Figure 6.5. 

The INVITE transaction is the only transaction in SIP that uses a three-way handshake, as opposed to a two-way handshake used by the rest. So, after the final response has been received by the UA, it will generate another request, called ACK, in order to acknowledge the reception of the final response. The reason for this different behavior will be explained in Chapter 7 when we look at the mechanisms that SIP uses in order to guarantee delivery of messages even when using unreliable transports such as UDP (User Datagram Protocol).

Figure 6.6 shows a complete INVITE transaction that initiates a session, including the ACK message.

Figure 6.6. 

A UAC generates a CANCEL request (Figure 6.7) in order to cancel a pending request. The CANCEL request is part of a different transaction, but it refers to the original transaction. The reception of a CANCEL request causes the UAs to stop processing the pending transaction. When a CANCEL request is received for a transaction that is already completed, it has no effect.

Figure 6.7. 

For instance, let us consider that Alice calls John, so her UA generates an INVITE request. When the INVITE is received by John’s UA, it sends back a 180 provisional response and starts alerting him. Nobody accepts the call for a while, and then Alice decides to hang up. She sends a CANCEL request to John, referring to the original INVITE. When the CANCEL request reaches John’s UA, the UA stops ringing, and the transaction is canceled. John’s UA generates a 200 OK response to the CANCEL transaction, but also a 487 “Request terminated” response to the original INVITE. Upon reception of the 487 response, Alice issues an ACK request to complete the three-way handshake.

The BYE request (Figure 6.8) is used to terminate a session. When a UAS receives a BYE request for an existing dialog, the UAS must terminate the session associated with that dialog (and therefore stop sending and listening for media).^[2]

Figure 6.8. 

The OPTIONS request (Figure 6.9) allows a UA to query a server about its capabilities. These capabilities include information about the supported methods, content types, extensions, codecs, and so on.

Figure 6.9. 

The From header field indicates the logical identity of the initiator of the request (i.e., the user’s Address of Record). This logical identity is typically expressed as a SIP URI. Because the From header field contains a logical identity, it is important that no IP addresses or FQDNs are present in it, but rather, an AOR. The From header field also contains a mandatory “tag” parameter. In our previous example, the From header field in the INVITE request generated by Alice might look like:

The “tag” parameter is used for identification purposes. More specifically, it is used, together with the Call-ID header field and the “tag” parameter in the To header field, in order to identify a dialog.

The From header field may also contain an optional field called Display-name that would be added before the SIP URI. Display-name represents a name that identifies the initiator of the request and that might be displayed to the destination party.

Usually the value that populates the From header field in requests generated by a particular UA is preprovisioned by the user or by the administrators of the user’s local domain.

The To header field specifies the logical recipient of the request—that is, the Address of Record of the user or resource that is the target of this request. This logical identity is typically expressed as a SIP URI. Example:

The UAC sets the To header field, and no proxy in the path can change it. The proxies in the path might make rerouting decisions. For instance, they might, based on local policy, decide to forward a request to another destination; however, the To header is not changed. Therefore, the To header field really represents the original intended recipient of the request. This may or may not be the ultimate recipient of the request. Figure 6.13 depicts this idea in a call-forwarding scenario.

Figure 6.13. 

A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book.

The optional “Display-name” is meant to be rendered by a human-user interface. Example:

The “tag” parameter, together with the Call-ID header field and the “tag” parameter in the From header field, serves as a general mechanism for dialog identification.

Only requests within a dialog must contain a To tag.

The Call-ID header field acts as a unique identifier to group together a series of messages. It is generated by the UA as a combination of a random string and the UA’s host name or IP address. The combination of the To tag, From tag, and Call-ID completely identifies a dialog. The Call-ID must be the same for all requests and responses sent within a dialog. Dialogs are explained in detail in Chapter 7.

The Call-ID is automatically generated by the UA, so no provisioning or human interface is required for the selection of the Call-ID header-field value for a request.

Example:

SIP responses have to follow the same path as the corresponding requests, only in reverse order. In order to achieve this, the Via header field is used. The Via header field indicates the path taken by the request so far, and so expresses the path that should be followed in routing the responses.

The Via header field includes two fields:

In addition, the Via header can contain one or more parameters such as “branch” or “received.”

Here is an example of the Via header field:

A UAC includes a Via header field in each request. It indicates the address where it expects to receive the responses. Every proxy in the path of the request adds its own Via header field so that responses traverse the same proxies as did the request. As the response makes its way back to the UAC, proxies delete the Via header field that they introduced in the request. Figure 6.14 shows this behavior.

Figure 6.14. 

Another function of the Via header field is to allow correlation of responses to requests in the same transaction. For this, the mandatory “branch” parameter is used. The “branch” parameter identifies the transaction. The UAC that creates the branch ID when sending a request has to assure its uniqueness across space and time for all requests sent by the UA. A CANCEL request contains the same “branch” parameter as the request it cancels.

The Via header field is also useful for detecting loops. Proxies are able to determine if a received request is looping just by looking at the Via header. The way this is done will be explained in Chapter 13, which deals with proxies.

Another important parameter in the Via header is the “received” parameter. When a server receives a request and the originating IP address as it appears in the IP layer does not correspond to the address in the topmost Via header, then the server adds a “received” parameter equal to the real IP address the request was sent from.

Let us consider that Alice has a multihomed UAC with two IP addresses: 5.4.3.2 and 5.4.3.1. f. She wants to set up a session with John, so first she sends an INVITE request to her outgoing proxy. The Via header in the request from UAC might look like:

Let us also assume that the origin IP address at the IP layer is 5.4.3.1. Alice’s proxy will detect such a situation, and add a “received” parameter to the Via header. Therefore, the Via headers that Alice’s proxy (proxy.ocean.com) will include in the outgoing request toward John’s proxy would be:

The Contact header field is generated by a UA, and provides a SIP URI that can be used to contact that specific instance of the UA for subsequent requests. This means that new requests within a dialog might be routed directly to the peer UA using the Contact address. In this way, SIP proxies that do not need to be in the signaling path after routing the first INVITE would be off-loaded. In order for this direct routing to be possible, the Contact header field typically contains a “location” SIP URI rather than a logical identity.

Example:

In Figure 6.15, we can see the utilization of the Contact header in a dialog. The BYE request is routed directly between John and Alice, based on the SIP URI that Alice included in the Contact header field of the initial INVITE request.

Figure 6.15. 

In a REGISTER request, the Contact header field represents the Contact Address that will be mapped to the Address of Record in the Location Service.

Both the Record-Route and the Route header fields (Figure 6.16) contain a list of SIP URIs. Each list identifies a series of SIP proxies. Therefore, they are “location” SIP URIs that either contain an IP address or an FQDN from which it is easy (possibly through DNS queries) to determine IP address, port, and transport to use.

Figure 6.16. 

The Route header field is used by UAs and proxies to force routing of a request through the listed set of proxies. For instance, a UA might include the preconfigured SIP URI of the outgoing proxy as the first entry in the Route header of every new request, thus assuring that such requests would traverse the outgoing proxy.

The Record-Route header field is inserted in a request by a proxy so as to force future requests in the dialog to be routed through it. The UA will copy the contents of the Record-Route header field in the received request into the Route header field of new requests generated within the dialog.

The Command Sequence (CSeq) header field (Figure 6.17) consists of a sequence number and a method.

Figure 6.17. 

Example:

The sequence number is used to order end-to-end requests within the same dialog. A UA generating requests within a dialog must increment by 1 the value of the sequence number in all subsequent end-to-end requests it sends. The peer UA keeps track of these values, and then can determine if a request within a dialog has arrived out of order.

The ACK and CANCEL requests do not cause the sequence number to be incremented because they are not always end-to-end requests, as will be explained in Chapter 13. The CANCEL request may, for instance, be created by a forking proxy. This situation occurs when a proxy starts two new transactions in order to make a parallel search. If a 200 OK is received in one of the transactions, the other transaction needs to be canceled. Thus, a CANCEL has to be sent by the proxy. Likewise, when a proxy receives a 300-699 response to an INVITE, it has to generate an ACK for that transaction. Therefore, ACK and CANCEL requests never increment the sequence number. Otherwise, they might interfere with the sequence numbers generated by the UAs. More specifically, CANCEL requests will always contain a CSeq equal to that of the transaction that they want to cancel. An ACK request generated as a consequence of receiving a 300-699 response will also contain the same CSeq as the INVITE it acknowledges.

The Method field is used to help in the correlation of requests and responses pertaining to the same transaction. We said, when we discussed the Via header, that transactions are identified using the “branch” parameter in the Via header field. That is true; however, CANCEL transactions contain the same branch value as the transaction that they cancel. So, in order to distinguish a response for a CANCEL from a response to the INVITE, the Method field, which will be different in the two cases, is used.

SIP requests can traverse several proxies. In order to limit the number of proxies that a request can traverse on the way to its destination, SIP requests carry the Max-Forwards header field, which contains an integer that is decremented at each hop. When the value of the Max-Forwards header field reaches 0, the request is rejected.

Example:

These SIP headers describe the message body, and thus will be presented in the next section.

The Content-Type header field indicates the media type of the message body sent to the recipient. As we already saw, SIP messages can contain an SDP object in the message body. Figure 6.18 shows a SIP message containing an SDP object.

Figure 6.18. 

A SIP message body could also contain several parts, each of them pertaining to a different media type. This can be done by using a composite MIME type called multipart, as depicted in Figure 6.19.

Figure 6.19. 

The Content-Length header field indicates the size of the message body, in decimal number of octets, sent to the recipient.

Example:

This header is used as a modifier to the media type. Its value indicates what additional encodings have been applied to the message body, and so lets the receiver know what decoding it has to apply in order to recover an object of the type indicated by the Content-Type header field. It is used primarily for compressing the message body.

Example:

This header extends the MIME Content-Type, and thus provides more information about how the message body should be interpreted. Some possible values are:

The old SIP specification RFC 2543, now obsolete, defined another approach to SIP routing, commonly referred to as “strict routing.” In this mode, the Request-URI always represents the SIP URI of the next hop. A SIP entity that wants to send a request to <sip:[email protected]> and that wants the request to traverse a predefined set of proxies should then set the Request-URI to the URI of the first proxy to be traversed. The Route header would then contain the remaining proxies plus the final destination, so that the last value can be retrieved by the last proxy in order to route to the final destination. Every proxy in the path would get the topmost Route header-field value and place it in the Request-URI in order to route the request to the next hop.

In order to understand the difference between loose and strict routing, let us consider a scenario where the originator of the request wants to send a request to sip:[email protected], and it wants it to force the request through two predetermined proxies (proxy 1, proxy 2).

Figure 6.20 shows this scenario in a “loose-routing,” approach, whereas Figure 6.21 represents the same scenario in a “strict-routing” approach.

Figure 6.20. 

Figure 6.21. 

The strict-routing approach is a legacy one, so we will not consider it anymore in this book. The reason we have presented this approach is for the reader to be aware of it because there are still some implementations in the market that use it.

The URI parameter “lr” is used to indicate that the element responsible for this resource implements loose routing. If it is not present, strict routing is assumed.

In the direct mode, the UA initiating the session (in our case, Alice’s UA) knows beforehand the IP address of the target UA (John’s UA). So, in this case, Alice might introduce the following SIP URI to indicate the destination of the call:

Alice’s UA would generate an INVITE request, and introduce this SIP URI in the Request-URI field (and also in the To header field). At the same time, it would derive the destination IP address from the SIP URI, which is straightforward, and select the default destination port (5060) and the default transport (UDP). At this point, John’s UA can send the message directly to Alice. There is no need for any proxy in between the two UAs. Figure 6.24 describes this scenario.

Figure 6.24. 

Regarding the routing of responses, these are sent back to the originator of the request thanks to the Via header field—which the originator includes in the request, and which contains its own IP address.

In the proxy-assisted mode, Alice does not know the IP address of John’s UA. All she knows is his SIP public identity in the form of a SIP URI:

As opposed to the SIP URI in the previous examples, this SIP URI does not indicate a location; it represents a “logical” identity. So, in this case, there is a need to query a Location Service and retrieve a “location” SIP URI from which the parameters needed to route the call (IP address, port, and transport) can be easily derived.

Obviously, the Location Service needs to have been previously populated with the Address of Record–to–Contact Address mapping that we saw in previous sections. That is typically done through the registration procedure.

Typically, John would be subscribed to a SIP service provider (in this case, called “Sea”). This company deploys a registrar, a proxy, and a Location Service. John registers with the registrar and Location Service. The proxy is an inbound proxy that responds for the domain sea.com and has the capability to query the Location Service. That proxy, proxy.sea.com, could also act as an outbound proxy for calls originated by John.

In this scenario, Alice would introduce John’s SIP URI (sip:[email protected]), and his UA would place it in the Request-URI of the INVITE message (and also in the To header field). Alice’s UA would need to route the request to the authoritative proxy for the domain sea.com—that is, it must send the request to John’s inbound proxy. For that, Alice’s UA needs to determine the address, port, and transport to use, for which it has to perform some DNS queries. Then the UA sends the message directly to the obtained IP address and port, using the obtained transport type. John’s inbound proxy receives the INVITE request and examines the domain (sea.com) in the Request-URI. It recognizes the domain as its own, for which it handles a Location Service. So proxy.sea.com queries the Location Service for the public identity sip:[email protected], and obtains a “location” URI sip:[email protected]. The proxy changes the SIP URI after the location query, and sends the message to the IP address in the new SIP URI.

This scenario is depicted in Figure 6.25.

Figure 6.25. 

In the previous scenario, it has been Alice’s UA that directly makes all the necessary DNS queries. Although this is definitely a possible scenario, it is more frequent to delegate those queries to an outbound proxy. This proxy—let us call it proxy.ocean.com—is deployed by Alice’s SIP provider (“Ocean”), and might also act as inbound proxy for incoming calls to Alice. In this new scenario, we have the familiar SIP trapezoid, which is the most usual architecture for SIP. This scenario is equivalent to the previous one, except that the DNS queries for the domain ocean.com are now performed by the outgoing proxy, and Alice’s UA has to make sure that all outgoing calls are sent to that proxy. This is usually achieved through configuration (static or dynamic) of Alice’s UA. When Alice initiates a session, her UA reads the “Outbound proxy” configuration parameter and puts it as the first entry in the Route header field (John’s address would go into the Request-URI) so the message would be routed first to proxy.ocean.com.

The SIP trapezoid scenario is depicted in Figure 6.26.

Figure 6.26. 

In a real SIP scenario, there might be even more than two proxies in the path. Those proxies could help in routing the call, and may need to make DNS queries.

Once the dialog has been established, subsequent requests within the dialog might need to traverse all the proxies or could just skip them. This depends on whether the proxies, during the dialog setup, decided to be included in the path of subsequent messages. Proxies signal that situation by including their SIP URI in the Record-Route header field of the INVITE message. New requests within the dialog can nevertheless be routed directly to the peer UA without the need to again query a Location Service, thanks to the fact that UAs include in the INVITE request a header field called Contact header, which represents a SIP URI that can be used to directly reach the UA.

The reader may wonder what the use is of having the proxies remain in the path after the call has already been routed. Actually, proxies may have some (limited) service logic. Let us imagine, for example, that a SIP provider wants to charge calls initiated by its subscribers. The provider somehow needs to generate a record indicating the duration of each call, together with the identity of the caller and the callee. A proxy that record-routes would be able to generate these records because it knows when the call starts and also when the call is released, and therefore it can measure the call duration.

In all the previous scenarios, responses follow the same path as requests—that is, they traverse the same proxies. This can be achieved thanks to the Via header field, which was explained in previous sections.

John’s soft phone may have two pieces of preconfigured information:

When John turns on his soft phone, it will automatically generate a REGISTER request such that:

Given that there is no Route header, the next-hop SIP URI is contained in the Request-URI. Following DNS procedures (not shown), it will be resolved into an IP address, port, and transport for forwarding the message.

The registrar creates a binding between John’s AOR and his location SIP URI, and returns a 200 OK message that indicates to John that the request was successfully performed.

Alice’s soft phone may have two pieces of preconfigured information:

In order to set up a voice and video session with John, Alice needs to do three things:

When Alice presses the “Call” button, her UA generates an INVITE message such that:

The SDP offer in the message body includes voice and video with the corresponding codecs.

Then the message is sent to the IP address of proxy.ocean.com, which would be obtained through a DNS A query (not shown in the diagram). By default, it uses UDP as a transport and destination port 5060.

(Alice’s SDP is not shown. It indicates voice and video media components.)

Alice’s outbound proxy receives the request, looks into the destination address (sip:[email protected]), and determines that it is not responsible for that domain. Thus, the next hop’s SIP URI is sip:[email protected]. At this point, and following the algorithm shown in Figure 6.22, the outgoing proxy will perform a number of DNS queries (NAPTR, SRV, and A) in order to retrieve the IP address, port, and transport to be used. The DNS determines that the next hop is proxy.sea.com (John’s inbound proxy), whose IP address is 1.1.1.1, and which has to be contacted using TCP and destination port 5060.

Alice’s outbound proxy opens a TCP connection against proxy.sea.com (if there was not already a connection open), and sends the INVITE request. We will assume that Alice’s outbound proxy does not need to be in the path of new requests generated within the dialog, so it does not add a Record-Route header.

(Alice’s SDP is not shown. It indicates voice and video media components.)

John’s inbound proxy receives the message, looks at the destination address (sip: [email protected]), and extracts the domain part (“sea.com”). The proxy realizes that sea.com is the domain for which it is responsible, hence it queries the Location Service for John’s address of record, sip: [email protected]. As a result, the proxy obtains John’s contact address as a SIP URI: <sip:[email protected]>. The proxy will then apply the algorithm in Figure 6.22 to determine the port and transport to use, which will be 5060 and UDP (the default ones), and then forwards the request message to John’s phone.

We will assume that John’s inbound proxy does not need to be in the path of new requests generated within the dialog, so it does not add a Record-Route header.

(Alice’s SDP is not shown. It indicates voice and video media components.)

John’s phone receives the message and alerts him to the incoming call from Alice so that he can decide whether to answer the call. While John decides if he takes the call or not, Alice should be informed that John is being alerted. Therefore, John’s phone automatically generates a 180 Ringing response message, which is routed back to proxy.sea.com based on the value in the received Via header.

Proxy.sea.com strips off the topmost value of the Via header, and sends back the response to the address indicated in the topmost Via header, which corresponds to proxy.ocean.com.

Proxy.ocean.com strips off the topmost value of the Via header, and sends back the response to the address indicated in the topmost Via header, which corresponds to Alice’s UA.

John accepts the call, so his UA generates a 200 OK response, which is routed to proxy.sea.com in the same way as the 180 provisional response (i.e., based on the Via header). The 200 OK response includes the SDP answer that indicates that John accepts a voice and video session with the offered codecs.

(John’s SDP is not shown. It accepts voice and video media components.)

Proxy.sea.com receives the 200 OK response, and routes it back to proxy.ocean.com in the same way as the 180 provisional response (i.e., based on the Via header).

(John’s SDP is not shown. It accepts voice and video media components.)

Proxy.ocean.com receives the 200 OK response, and routes it back to Alice’s UA in the same way as the180 provisional response (i.e., based on the Via header).

(John’s SDP is not shown. It accepts voice and video media components.)

Given that the proxies in the path did not record-route, Alice’s UA generates and sends an ACK request directly to John’s UA, based on John’s contact address received in the Contact header of the 200 OK response.

The media is established, and John and Alice can talk to each other and see each other.

Alice wants to remove the video component in the session, so she sends a new INVITE request with a new SDP that includes only audio.^[6] The request goes directly to John by using his contact URI (sip:[email protected]).

(Alice’s SDP is not shown. Port in the video component is set to 0.)

John’s UA accepts the session modification and sends back a 200 OK, including a new SDP answer that includes only audio.

(John’s SDP is not shown. Port in the video component is set to 0.)

Alice’s UA sends an ACK message.

John and Alice can still talk to each other, but they no longer see each other.

John now wants to terminate the session, so he sends a BYE request directly to Alice’s contact URI (sip:[email protected]), which was obtained by Alice’s UA from the Contact header field in the initial INVITE.

Alice responds with a 200 OK, and the session is terminated.