SIP Protocol Resolution and implementation (C and C ++ use Osip) 12

Chapter 9 dialogue

A key concept for user proxy is dialog. A dialog indicates a point-to-point sip connection between two user proxies at some time. The dialog ensures that messages between user proxies are ordered and correctly routed. A dialog indicates the context of a SIP message. Rfc3261 the UA processing discussed in section 8th is irrelevant to the method. This chapter discusses how to construct a dialog and how to send subsequent requests and responses in the dialog.

A dialog is identified by a dialog ID in each UA, which consists of a call-id value, a local tag, and a remote tag. The dialog IDs of the same conversation in each UA are not the same. The local tag of an UA is the same as the remote tag of the Peer UA. Flag is an opaque mark, which ensures that a globally unique dialog ID is constructed.

The dialog ID is also related to all the tags that contain the to header fields in the response and request. The rule for calculating the conversation ID of a message depends on whether the SIP element is UAC or UAS. If it is UAC, the call-id value in the dialog ID is set to the call-ID of the message, and the tag value in the to header field of the message is remotely marked, the local tag is set to the value of the tag in the From header field of the message (these rules apply to requests and responses ). If it is UAS, the call-id value in the dialog ID is set to the call-ID of the message, and the remote tag value is set to the tag value of the From header field of the message, the label value of the to header field where the local tag is set as a message.

A dialog contains certain statuses for future message transmission in the dialog. These statuses are sorted by the conversation ID, a local serial number (used to sort the requests from the UA to the peer end), and a remote serial number (used to sort the requests from the peer end to the UA ), A local Uri, a remote Uri, a remote destination, a Boolean sign called "secure", and a routing set of a URI sequence. A route set is a list of servers that send messages to the peer end that need to be crossed. A dialog can also be set to the "early" status, which is created by a temporary response and converted to the "Confirmed" status after receiving the 2XX final response. If other or no response is received, the "early" dialog will be terminated.

Section 1 create a dialog

Creates a dialog by constructing a non-Failed response to a request for a specific method. In this manual, only 2XX and 101-199 responses to invite requests will create a dialog. A dialog created for a non-final response to a request is in the "early" state and called an early dialog. Extensions can define other meanings for dialogs. Rfc3261 section 13th describes the invite method in detail. Here we describe how to process the dialog creation status that does not depend on the method.

The UA must assign a value for the part of the dialog ID as described above.

UAS Behavior

When a UAS responds to a request and creates a dialog (like 2XX response to invite ), UAS must copy the values of all record-route header fields from the request to the response (including the URI, URI parameters, and parameters of any record-route header fields, regardless of whether UAS knows the meaning of these values), and UAS must maintain the order of these values. UAS must add a contact header to the response. The contact header field contains the address of the UAS that you want to use for subsequent requests in the dialog (in the case of the invite method, these subsequent requests include ack for a 2XX response ). Generally, the host part of this URI is the IP address or the FQDN of the host. The URI provided in the contact header must be a sip or sips uri. If the request to initiate a dialog contains a sips uri in the request-URI or the top-level record-Route Header field, or if the record-Route Header field does not exist, the top-level contact header field contains a sips uri, the contact header field in the response must be a sips uri. This URI should be global (that is, the same URI can be used in messages outside the dialog ). In the same way, the URI range in the invite contact header is not restricted in this dialog. Therefore, it can be used by UAC in messages outside the dialog.

This is the state of the UAS session. This status must be maintained throughout the session.

If the request is sent using TLS and the request-Uri contains a sips uri, the "secure" label is set to true.

The route set must be set to the URI list in the requested record-Route Header field. To keep the list order and keep the parameters of all Uris. If the request does not contain a record-Route Header domain, the route set must be set to an empty set. This routing set, even if it is an empty set, must ignore the existing routing, which is used by the requests in this dialog. The remote target must be set to the URI in the requested contact header.

The remote serial number must be set to the serial number value in the CSeq Header field of the request. The local serial number must be null. The call-ID that constitutes the conversation ID must be set to the call-id value in the request. The local tag that makes up the conversation ID is the tag of the to header field in the response to the original request (the to header field of the response usually contains a tag ), the remote tag that constitutes the dialog ID must be set as the From header field tag in the request. UAS must be prepared to receive a request with no tags in the From header domain. In this case, the tag is considered to contain a null value.
This is to ensure backward compatibility with rfc2543. It requires that the From header domain cannot have tags.

The remote URI must be set to the URI in the From header field, and the local URI must be set to the URI in the to header field.

UAC Behavior

When a UAC sends a request that can establish a conversation (like an invite), it must provide a global sip or sips uri (for example, the same sip URI can be used by messages outside the conversation ). If the request contains the value of a request-Uri header or a top-level Route Header and the value is a sips uri, the contact header must contain a sips uri.

When a UAC receives a response that establishes a session, it creates the dialog state. This status must be maintained throughout the session.

If the request sent is based on TLS and the request-Uri contains a sips uri, the "secure" flag is set to true.

The route set must be set to the URI list of the response record-Route Header domain and maintain their order and the parameters of all Uris. If there is no record-Route Header field in the response, the path game must be set to an empty set. This routing set, even if it is an empty set, must ignore the existing routing, which is used by the requests in this dialog. The remote target must be set as the URI in the response contact header.

The local serial number must be set to the serial number value of the requested CSeq Header field. The remote serial number must be null (created when the remote UA sends a dialog request ). The call-ID component of the conversation ID must be set to the value of the call-ID of the request. The local tag of the dialog ID must be set to the tag value of the From header field of the request, and the remote tag of the dialog ID must be set to the tag value of the to header field of the response. UAC must be prepared to receive a response without a tag in the to header domain. In this case, the value of this tag is considered null.
This is to ensure backward compatibility with rfc2543. It requires that the to header domain cannot have tags.

The remote URI must be set to the uri of the to header field, and the local URI must be set to the uri of the From header field.

Section 2 dialog box requests

Once a conversation is created in two UA instances, each end of the conversation needs to initialize a new transaction. When a UA sends a request, it uses this transaction as the UAC role. The UA receives the request as a UAS role. Note that UA may assume different roles from the transactions in which the conversation is established.

The request in the dialog may contain the record-route and contact header fields. Even though these requests may change the URI of the remote target, they do not change the route set of the conversation. When a request is not a target request, it cannot modify the remote target URI of the dialog. Only when the request is a target refresh request can the remote target URI of the dialog be changed. For a conversation established by invite, the only request to refresh the target is re-invite (see rfc3261 section 14th ). Other extension protocols may define other refresh target requests for Sessions established by other methods.
Note that ack is not a target refresh request.

The target refresh request can only update the URI of the remote target of the dialog, but cannot update the route set specified by the record-Route Header domain. Updating a route set will result in backward compatibility with rfc2543.

UAC Behavior

CREATE request

Creates a request in a dialog using the components of the dialog state. The dialog state is stored as a part of the dialog.

The uri of the to header field in the request must be set to a remote URI in the dialog state. The tags in the to header field in the request must be set as the remote tag of the conversation ID. The From header field of the request must be set to the local URI in the dialog state. The From header field label in the request must be set to the local tag in the dialog ID. If the remote or local tag is empty, the labels of the to or from header fields must be ignored.

The use of the URI of the original request to and from header is to be backward compatible with rfc2543, and rfc2543 uses the URI as the identifier of the conversation. In this manual, only tags are used for conversation identifiers. In subsequent revisions to this manual, this requirement to force the original to and from URI reflected in the Session Request is canceled.

The call-ID of the request must be set to the call-ID of the conversation. In a dialog, the request must contain the number of CSeq sequences that follow the increment strictly and are nearing (1 each time) (except ack and cancel, of course, their numbers are equal to the number of requests to be notified and canceled ). Therefore, if the number of local sequences is not empty, the value of the number of local sequences must be incremented by 1, and this value must be set to the CSeq Header domain. If the value of the number of local sequences is null, You must select an initial value according to the guidelines in section 8.1.1.5 of rfc3261. The method field in the CSeq Header must match the method field in the request.

When a 32-bit integer is used, a client constructs a request every second in a separate call, and the request will be used up in 136. The initial value of the number of sequences does not limit subsequent requests in the same call. A non-zero initial value allows the client to use time-based sequence numbers. For example, the client can select the maximum valid 31 bits in 32-bit seconds as the initial sequence number ).

UAC uses remote targets and route sets to construct the request-Uri and route header fields.

If the route set is empty, UAC must write the remote URI to request-Uri. In addition, the UAC must not add the Route Header domain to the request.

If the route set is not empty and the first URI in the route set contains the LR parameter (rfc3261 section 19.1.1), UAC must write the remote URI to the request-Uri, it must contain a Route Header domain that contains the Route Set Value and all parameters in order.

If the route set is not empty and the first URI in the route set does not contain the LR parameter, UAC must write the first URI in the route set to request-Uri, delete all parameters not allowed in request-Uri. UAC must contain the Route Header field, which contains all the remaining values and parameters in the route set in order. UAC must write the remote URI to the last value of the Route Header field.

For example, if the remote target is SIP: user @ remoteua and the route set includes:
<SIP: proxy1>, <SIP: proxy2>, <SIP: proxy3; LR>, <SIP: proxy4>
The request will contain the following request-Uri and route header fields:
Method SIP: proxy1
Route: <SIP: proxy2>, <SIP: proxy3; LR>, <SIP: proxy4>, <SIP: user @ remoteua>

If the first URI in the route set does not contain the LR parameter, it indicates that the proxy server does not understand the routing mechanism described in this document, as described in rfc2543, the first value in the Route Header domain is used as the request-Uri of the message to be sent. Save request-URI in the end of the Route Header field to save the information of traversing strict proxy in request-Uri (this information is returned when a loose proxy server is encountered ).

A uac should include the contact header field in the target refresh request in any dialog, And the URI should be consistent with the request in the previous dialog unless it needs to be changed. If the secure flag is true, the URI must be a sips uri. In rfc3261 section 12.2.2, we discuss the Contact Header domain used to update the target refresh request of the remote target Uri. This allows UA to provide a new contact address to change its address during a conversation.

However, non-target refresh requests cannot affect the remote URI in the dialog.

Description of section 8.1.1 of rfc3261 in the composition of the rest of the request.

Once a request is built, the computing server address and the sending request are processed in the same steps as the external request (rfc3261 Section 8.1.2 ).

The process in Section 8.1.2 of rfc3261 usually sends requests to the value at the top of the Route Header field. If there is no Route Header field, the address identified by request-Uri is used. Under certain restrictions, requests are allowed to be sent to another specified address (for example, an external proxy server that is not specified in the routing set ).