Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would be routed to that domain. In most cases, this means that the domain of the registration will need to match the domain in the URI of the address-of-record.
There are many ways by which the contents of the location service can be established. One way is administratively. In the above example, Bob is known to be a member of the engineering department through access to a corporate database. This mechanism is known as registration.
This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. An illustration of the overall registration process is given in Figure 2.
Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for purposes of Rosenberg, et. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements.
SIP does not mandate a particular mechanism for implementing the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data.
Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of- record.
To: The To header field contains the address of record whose registration is to be created, queried, or modified. The value is the same as the To header field unless the request is a third- party registration. The value is a number indicating seconds.
If this parameter is not provided, the value of the Expires header field is used instead. For example, Carol, with address-of-record "sip:carol chicago. Her registrations would then be used by a proxy server in the chicago. Once a client has established bindings at a registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar.
Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses. As described in Section There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an "expires" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the "expires" parameter.
This list can be prioritized with the "q" parameter in the Contact header field. The "q" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record.
A client can attempt to influence the expiration interval selected by the registrar as described in Section The UA compares each contact address to see if it created the contact address, using comparison rules in Section If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value.
A UA can be configured, in ways beyond the scope of this specification, with a registrar address. For example, the UA for the user "sip:carol chicago. Finally, a UA can be configured to use multicast. Multicast registrations are addressed to the well-known "all SIP servers" multicast address "sip. No well- known IPv6 multicast address has been allocated; such an allocation will be documented separately when needed.
SIP UAs MAY listen to that address and use it to become aware of the location of other local users see [ 33 ] ; however, they do not respond to the request. Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the same local area network. An immediate re-attempt is likely to also timeout.
Waiting some reasonable time interval for the conditions causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated. A registrar handles requests according to Section 8. A registrar MUST not generate 6xx responses. A registrar has to know for example, through configuration the set of domain s for which it maintains bindings.
If not, and if the server also acts as a proxy server, the server SHOULD forward the request to the addressed domain, following the general behavior for proxying messages described in Section Mechanisms for the authentication of SIP user agents are described in Section Registration behavior in no way overrides the generic authentication framework for SIP.
If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request.
The registrar SHOULD determine if the authenticated user is authorized to modify registrations for this address-of-record. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings.
If the authenticated user is not authorized to modify bindings, the registrar MUST return a Forbidden and skip the remaining steps. In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record.
The registrar extracts the address-of-record from the To header field of the request. The result serves as an index into the list of bindings. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a Invalid Request and skip the remaining steps.
If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding.
Otherwise, the update MUST be aborted and the request fails. The registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows: - If the field value has an "expires" parameter, that value MUST be taken as the requested expiration.
The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of Interval Too Brief. This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. It then skips the remaining steps. Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale.
The expiration interval of a registration is frequently used in the creation of services. An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance.
If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above.
If not, the update MUST be aborted and the request fails. This algorithm ensures that out-of-order requests from the same UA are ignored. The binding updates MUST be committed that is, made visible to the proxy or redirect server if and only if all binding updates and additions succeed. If any one of them fails for example, because the back-end database commit failed , the request MUST fail with a Server Error response and all tentative binding updates MUST be removed.
The registrar returns a OK response. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc.
This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. This may indicate that the target is unreachable and hence unavailable. An OPTIONS request received within a dialog generates a OK response that is identical to one constructed outside a dialog and does not have any impact on the dialog.
The response does not contain a message body. Contact header fields MAY be present in a OK response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them.
The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog.
The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs.
A dialog ID is also associated with all responses and with any request that contains a tag in the To field. As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message. A dialog contains certain pieces of state needed for further message transmissions within the dialog.
This state consists of the dialog ID, a local sequence number used to order requests from the UA to its peer , a remote sequence number used to order requests from its peer to the UA , a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer.
A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates. A dialog established by a non-final response to a request is in the "early" state and it is called an early dialog.
Extensions MAY define other means for creating dialogs. Here, we describe the process for creation of dialog state that is not dependent on the method. If the request that initiated the dialog contained a Rosenberg, et. It can therefore be used in messages to the UAC even outside this dialog. The UAS then constructs the state of the dialog. This state MUST be maintained for the duration of the dialog.
This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The local sequence number MUST be empty. This is to maintain backwards compatibility with RFC , which did not mandate From tags. This is to maintain backwards compatibility with RFC , which did not mandate To tags. Note that these may be different roles than the UAs held during the transaction that established the dialog.
However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do.
For dialogs that have been established with an Rosenberg, et. Other extensions may define different target refresh requests for dialogs established in other ways. Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route.
Updating the latter would introduce severe backwards compatibility problems with RFC -compliant systems. 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. 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.
If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8. 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 bit second clock as an initial sequence number.
If the route set is not empty, and the first URI in the route set contains the lr parameter see Section 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. Once the request has been constructed, the address of the server is computed and the request is sent, using the same procedures for requests outside of a dialog Section 8.
The procedures in Section 8. Subject to certain restrictions, they allow the request to be sent to an alternate address such as a default outbound proxy not represented in the route set.
If the client transaction returns a timeout, this is treated as a Request Timeout response. The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8. Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request.
If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. The UAS will receive the request from the transaction layer. If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs.
If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside of a dialog, discussed in Section 8. If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different possibly failed UAS the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery.
Another possibility is that the incoming request has been simply misrouted. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers.
They are processed as if they had been received outside the dialog. If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request.
If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a Server Internal Error response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order.
It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. The resubmitted request will have a new CSeq number. Such a gap does not represent any error condition. The mechanism for terminating confirmed dialogs is method specific.
In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. These UASs will frequently need to query the user about whether to accept the Rosenberg, et.
After some time, those UASs can accept the invitation meaning the session is to be established by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses 1xx to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response.
The procedure for sending this ACK depends on the type of response. For final responses between and , the ACK processing is done in the transaction layer and follows one set of rules See Section All these dialogs are part of the same call. An Allow header field Section A Supported header field Section It enumerates all the extensions understood by the UAC. The Accept header field is especially useful for indicating support of various session description formats.
Section 8. There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is "session". The offer indicates the desired communications means audio, video, games , parameters of those means such as codec types and addresses for receiving media from the answerer. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer.
This results in restrictions on where the offers and answers can appear in SIP messages. The usage of offers and answers is further restricted. In this specification, that is the final 2xx response. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction.
Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx and possibly in a 1xx as well, with the same value , or the offer is in the 2xx, and the answer is in the ACK. The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition header field value is "session". This results in the construction of a client transaction that will ultimately send the request and deliver responses to the UAC.
If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section Header fields present in a provisional response are applicable as long as the dialog is in the early state for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while this is in the early state. Depending on the status code of the 3xx response see Section Subsequent final responses which would only arrive under error conditions MUST be ignored.
All early dialogs are considered terminated upon reception of the non-2xx final response. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section Note that the only piece of state that is recomputed is the route set.
Other pieces of state such as the highest sequence numbers remote and local sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example.
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. Once the ACK has been constructed, the procedures of [ 4 ] are used to determine the destination address, port and transport. However, the request is passed to the transport layer directly for transmission, rather than a client transaction. At this point all the early dialogs that have not transitioned to established dialogs are terminated.
It first performs the request processing procedures of Section 8. Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps: 1. When the timer fires, the invitation is considered to be expired. If the request is a mid-dialog request, the method-independent processing described in Section It might also modify the session; Section 14 provides details.
If the request has a tag in the To header field but the dialog identifier does not match any of the existing dialogs, the UAS may have crashed and restarted, or may have received a request for a different possibly failed UAS. Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session.
This can happen when a user is invited to the same multicast conference by multiple other participants. For example, SDP Rosenberg, et. If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE that is, send a 2xx response without prompting the user.
The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formulates a response using the procedures described in Section 8. This is accomplished with a provisional response between and These provisional responses establish early dialogs and therefore follow the procedures of Section However, these will not be delivered reliably.
A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non provisional response at every minute, to handle the possibility of lost provisional responses. An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call.
However, it is unlikely that a UAS will be able to know this in general, and thus this response will not usually be used. This response establishes a dialog, and therefore follows the procedures of Section Including these header fields allows the UAC to determine the features and extensions supported by the UAS for the duration of the call, without probing.
Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds T1 and T2 are defined in Section Response retransmissions cease when an ACK request for the response is received.
And you believe it or not? But the question now becomes. Importantly, this end-to-end treatment is needed so that a caller knows the entire set of in-between proxies that have accepted the call. A bit dive into the structure of SIP elements. The client transaction sends the request, and the server transaction sends the response. The client and server transactions are logical functions that are embedded in any number of elements. In our case, they exist within user agents and stateful proxy servers, and guess what?
Only the first response non is forwarded internally from transaction layer to the TUs, later re-transmissions are processed dependently at transaction layer. Active 5 years, 6 months ago. Viewed 4k times. Geetha Geetha 11 1 1 silver badge 3 3 bronze badges. It's not a transaction. Quickly looking at the rfc, I don't see where it is written that ACK for 2xx would be a transaction Add a comment.
Active Oldest Votes. Hence in this case, the ACK is within the transaction. Sign up or log in Sign up using Google. However we would not be discussing the exact routing mechanism as of now.
At this point the UA2 come to know the address of UA1 which is available in the Contact header field of the incoming Invite. Till this point the UA1 is not aware of the exact location of the UA2 and has to still rely on the intermediate routing entities for the delivery of any other message if generated. And since the Invite transaction was complete as soon as OK was received, A new transaction is created for ACK and it is delivered end to end.
This also helps to keep the network clean and manage the network dynamics well. There is only one reason I mostly care for, i. Further from RFC , the response of a request or messages within a transaction take the exact path which the initial transaction initiating request took.
Please ignore this para if it confuses you ]. Local handling of the transaction if a error response is received for an INVITE makes sense as the leg which receives it first processes it first to completion and also intimates the another call leg of the same, and eventually all gets handled as soon as they are received.
Whereas ACK as a part of the same Invite transaction for all other final responses is actually the exception. I try to learn and get better. View all posts by abhishek chattopadhyay. Hence ACK needs to be end-to-end not hop-by-hop. A hop by hop request is effectively a request which is acted upon processed on each hop where it is received.
In short the purpose of ACK is not to acknowledge media exchange, rather it is majorly intended to indicate that the SIP dialog has either established or the transaction is completed. It additionally can do many other things which probably you are aware of.
ACK sent for OK during dialog establishment and after that are handled similarly. For that matter, ACK sent for 3, 4, 5, 6XX response prior to dialog establishment and after it are also treated similarly. Not doing so would require a lot of profiling and that would make the protocol more complex. Passion sip: That would be because an error response can be generated by any ua in the network and all error responses are treated hop by hop.
ACK for a OK is treated as separate transaction, Just becuase both the end point now know each other well with the contact address in OK. So ACK goes end — to — end creating a new transaction. ACK for any other final response is not treated as a separate transacation, Why?. Although 2xx, 3xx, 4xx , 5xx and 6xx all are categorized as final responses, still the 2xx responses for an Invite are special.
0コメント