RFC3261(SIP)读书笔记

noiile

Noiile@hotmail.com

SIP Message

A minimum SIP request

•A valid SIP request, at a minimum, must contain the following header fields:

•To

•From

•CSeq

•Call-ID

•Max-Forwards

•Via

•Request-Line(method, Request-URI, SIP version)

Request-URI

•The initial Request-URI of the message should be set to the value of the URI in the To Field.(except the REGISTER method)

To

•A UA may learn how to populate the To header field for a particular request in a number of ways.

•From human interface(a string of digits or letters)

•From address book.

•May be it is not a complete URI, it is at the discretion of the UA to choose how to interpret this input(for example: bob, 119)

•Since no dialog is established, no tag is present

From

•The From header field indicates the logical identity of the initiator of the request.

•The From header field in requests generated by a particular UA,  is pre-provisioned by the user.

•The From field must contain a new tag parameter, chosen by the UAC

Call-ID

•The Call-ID header field act as a unique identifier to group together a series of messages.

•It must be the same for all requests and responses sent by either UA in a dialog.

•It should be the same in each registration from a UA.

•Note that when requests are retried after certain failure responses that solicit an amendment to a request(for example, a challenge for authentication), these retried request are not considered new requests, and therefore do not need new Call-ID header fields

•Implementations may use the form localid@host

•No provisioning or human interface is required for the selection for the Call-ID header field value

CSeq

•The CSeq header field serves as a way to identify and order transactions.

•It consists of a sequence number and a method(CSeq : 4711 INVITE).

•The sequence number value must be expressible as a 32-bit unsigned integer and must be less than 2**31.

Max-Forwards

•The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination.

•It consists of an integer that is decremented by one at each hop.

•If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected by a 483 error response.

•The value should be 70, or only in networks where topologies are known by the UA.

Via

•The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent.

•When the UAC creates a request, it must insert a Via into that request.

•The Via header field value must contain a branch parameter. It is used to identify that the transaction created by that request.

•CANCEL and ACK for a non-2xx response will have the same value of the branch parameter as the INVITE.

•The branch ID must always begin with the characters “z9hG4bK”.

•The Via header maddr, ttl, and sent-by components will be set when the request is processed by transport layer.

Contact

•The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests.

•This URI must be valid even if used in subsequent request outside of any dialogs.

Supported and Require

•Supported

•Require

•Proxy-Require

•These fields contain a list of option tags, that are understood by the UAs or Proxy.

UA Generic Behavior

Processing Responses

•A UAC must treat any final response it does not recognize as being equivalent to the x00 response code of that class. And must be able to process the x00 response code for all classes.

•A UAC must be able to process 100 and 183 responses.

•If more than one Via header field value is present in a response, the UAC should discard the message.

Processing 3xx Responses

•Upon receipt of a redirection response, clients should use the URIs in the Contact header field to formulate one or more new requests based on the redirected request.

Processing 4xx Responses

•401(Unauthorized) or 407(Proxy Authentication Required)

•413(Request Entity Too Large)

•415(Unsupported Media Type)

•              Accept, Accept-Encoding, Accept-Language

•416(Unsupported URI Scheme)

•420(Bad Extension)

•              Unsupported

•When response as above is received, the UAC should retry the request using the same Call-ID, To, From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous.

Processing Requests

•If  a request is received, UASs should process it in the order of the steps as following:
authentication(optional)

•   inspecting the method

•   inspecting the header

•   processing content

•   applying extensions

•   processing the request

•   generating the response

Method Inspection

•If the UAS recognizes but does not support the method of a request, it must generate a 405(Method Not Allowed) response.

•The UAS must add an Allow header field to the 405 response.

Header Inspection

•The server must ignore that can not understand header field and continue processing the message.

•If the UAS decides to reject the request, it should respond 403(Forbidden).

•If the Request-URI uses a scheme not supported by the UAS, should respond 416.

•If the Request-URI does not identify an address that UAS is willing to accept requests for, should reject with a 404.

•If the request has no tag in the To header field, the UAS core must check the request against ongoing transactions.

•If the request does not match that transaction but the From tag, Call-ID, and CSeq exactly match those associated, the UAS core should respond 482(Loop Detected)

•If the request present the Require header field, and UAS does not understand,  it must respond 420 with Unsupported header field.

•Note that Require and Proxy-Required must not be used in CANCEL/ACK for a non-2xx response. Ignore it if presents.

Content Processing

•If there are any bodies whose type(Content-Type) , language(Content-Language) or encoding(Content-Encoding) are not understood, and the body part is not optional(as indicated by the Content-Disposition) the UAS must reject with 415(Unsupported Media Type).

•The response must contain an Accept/Accept-Encoding/Accept-Language which header field in the request it can not understand.

Applying Extensions

•The server must not apply extensions not listed in the Supported header field in the request. And the server may send a 421(Extension Required) response.

Generating the Response

•UASs should not issue a provisional response for a non-INVITE request, it should generate a final response to a non-INVITE request as soon as possible.

 •When a 100 response is generated, any Timestamp header field present in the request must be copied into this response.

•If delay, add a delay value into the Timestamp value.

•The From/Call-ID/CSeq must equal the same field of the request. •If the To header field in the request did not contain a tag, the UAS must add a tag to the To header field in the response.

•The same tag must be used for all responses to that request, both final and provisional.

Canceling a Request

•The CANCEL request is used to cancel a previous request sent by a client.

•CANCEL has no effect on a request to which a UAS has already given a final response.

•A UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would “stop ringing”, and then respond to the INVITE with a specific error response(487).

•CANCEL requests can be constructed and sent by both proxies and user agent clients.

CANCEL-Client Behavior

•A CANCEL request should not be sent to cancel a request other than INVITE.

•The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request must be identical to those in the request being cancelled, including tags.

•If no provisional response has been received, the CANCEL request must not be sent.

•The destination address, port, and transport for the CANCEL must be identical to those used to send the original request.

CANCEL-Server Behavior

•If the UAS did not find a matching transaction for the CANCEL, it should respond to the CANCEL with a 481(Call Leg/Transaction Does Not Exist).

Registrations

•A REGISTER request does not establish a dialog.

•A UAC may include a Route header field in a REGISTER request based on a pre-existing route set.

•The Record-Route header field has no meaning in REGISTER requests or responses, must be ignored if present.

•The following header fields, except Contact, must be included in a REGISTER request. A Contact header field may be included:

•Request-URI: The userinfo and “@” components of the SIP URI must not be present.(for example, sip: Chicago.com).

•To: The To header field contains the address-of-record whose registration is to be created,queried, or modified.

•From: The same of the To header.

•Call-ID: All registrations from a UAC should use the same Call-ID header field value for registrations sent to a particular registrar.

•CSeq: A UA must increment the CSeq value by one for each REGISTER request with the same Call-ID.

•Contact:  May contain a Contact header field with zero or more values containing address bindings.

•UAs must not send a new registration until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out.

•Expires/expires Contact header parameter

•The q parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record.

Removing Bindings

•A UA requests the immediate removal of a binding by specifying an expiration interval of “0” for that contact address in a REGISTER request. •The REGISTER-specific Contact header field value of “*” applies to all registrations, but it must not be used unless the Expires header field is present with a value of “0”.

Transmitting a Request

•If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC should not immediately re-attempt a registration to the same registrar.

Error Responses

•If a UA receives a 423(Interval Too Brief) response, it may retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 response.

Registrar

•A registrar is a UAS that responds to REGISTER request and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain.

•But it accepts only REGISTER requests.

•A registrar must not generate 6xx responses.

•One common usage would be for a registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast interface with a 302 response.

•Registrars must ignore the Record-Route header field if it is included in a REGISTER request.

Processing REGISTER

•Inspects the Request-URI to determine whether it has access to bindings for the domain identified in the Request-URI.

•The registrar must process the Require header field values as described for UASs.

•A registrar should authenticate the UAC.

•The registrar should determine if the authenticated user is authorized to modify registrations for this address-of-record. If not, return 403.

•Check the address-of-record from the To header field of the request, if not valid, return 404.

•Check whether the request contains the Contact header field.

• If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value “*” and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (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.

•Process each contact address in the Contact header field in turn. •Return 200 , the response should include a Date header field.

Querying for Capabilities

•OPTIOS allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without “ringing” the other party.

•If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part. Similar to the way a Request-URI is set for a REGISTER request.

•Allow, Accept, Accept-Encoding, Accept-Language, Supported.

•A message body may be sent, the type of which is determined by the Accept header field in the OPTIONS request.

Dialog

Dialog Introduction

•A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. •A dialog is identified at each UA with a dialog ID(Call-ID, local tag, remote tag). •The dialog state consists of the dialog ID, a local sequence number, a remote sequence number, a local URI, a remote URI, a remote target, a boolean flag called “secure”, and a route set.

Creation of a Dialog

•Dialogs are created through the generation of non-failure responses(2xx and 101-199 with a To tag) to requests(INVITE) with specific methods.

UAS behavior

•When a UAS receives a INVITE message, it must do as following:

•Must copy all Record-Route header field values from the request into the response(including parameters), and must maintain the order of those values.

•Must add a Contact header field to the response.

•Constructs the state of the dialog, and maintain it for the duration of the dialog.

•Must set To tag.

UAC Behavior

•When a UAC sends a request that can establish a dialog it must provide a SIP or SIPS URI with global scope in the Contact header field of the request. •When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state must be maintained for the duration of the dialog.

Request within a Dialog

•For dialogs that have been established with an INVITE, the only target refresh request defined as re-INVITE.

•ACK is not a target refresh request.

UAC  Behavior

•Requests within a dialog must contain strictly monotonically increasing and contiguous CSeq  sequence numbers in each direction(excepting ACK and CANCEL). •The UAC uses the remote target and route set to build the Request-URI and Route header field of the request.

•If the route set is empty, the UAC must place the remote target URI into the Request-URI. The UAC must not add a Route header field to the request.

•If not empty, and the first URI in the route set contains the lr parameter(means that proxy understand the routing mechanisms), the UAC must place the remote target URI into the Request-URI and must include a Route header field containing the route set values in order, including all parameters.

•If the route set is not empty, and its first URI does not contain the lr parameter, the UAC must place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI.

•The UAC must add a Route header field containing the remainder of the route set values in order, including all parameters,

•The UAC must then place the remote target URI into the Route header field as the last value.

•A Contact header field in a target refresh request update the remote target URI.

•Requests that are not target refresh requests do not affect the remote target URI for the dialog.

•When a UAC receives a 2xx response to a target refresh request, it must replace the dialog’s remote target URI with the URI from the Contact header field in that response, if present.

•The UAC should terminate the dialog when a 481 or a 408 is received, or no response at all is received for the request.

UAS Behavior

•Based on the To tag, the UAS may either accept or reject the request. •Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. •When a UAS receives a target refresh request, it must replace the dialog’s remote target URI with the URI from the Contact header field in that request, if present.

Termination of a Dialog

•The BYE method terminates a session and the dialog associated with it.

Session

Initiating a Session

•When a user agent client desires to initiate a session(for example, audio, video, or a game), it formulates an INVITE request.

•The INVITE request asks a server to establish a session.

•Once UAC receives a final response, it needs to send an ACK for every final response it receives.

•For final responses between 300 and 699, the ACK processing is done in the transaction layer.

•For 2xx responses, the ACK is generated by the UAC core.

•A UA that supports INVITE must also support ACK, CANCEL, and BYE.

UAC Creating the Initial INVITE

•An Allow header field should be present in the INVITE. It indicates what methods can be invoked  within a dialog.

•A Supported header field should be present in the INVITE.

•An Accept header field may be present in the INVITE.

•The UAC may add an Expires header field to limit the validity of the invitation. If the time indicated in the Expires header field is reached and no final answer for the INVITE has been received, the UAC core should generate a CANCEL request for the INVITE.

•Other useful headers: Subject, Organization, User-Agent.

Session description

•SIP uses an offer/answer model where on UA sends a session description. •The offer indicates the desired communications means(audio, video, games), parameters of those means and address 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.

•An offer/answer exchange is within the context of a dialog.

•There are two exchanges:

•The offer is in the INVITE, and the answer in the 2xx

•Or the offer is in the 2xx, and the answer is in the ACK.

•All user agents that support INVITE must support these two exchanges.

•Content-Type, Content-Disposition, Content-Language

UAC Processing INVITE Responses

•1xx: Header fields present in a provisional response are applicable as long as the dialog is in the early state. •3xx: A 3xx response may contain one or more Contact header field values providing new addresses where the callee might be reachable. Depending on the status code of the 3xx response, the UAC may choose to try those new addresses.

•456xx:456xx may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses must be ignored. •All early dialogs are considered terminated upon reception of the non-2xx final response.

UAC Processing INVITE Responses-2xx

•If the offer in the 2xx response is not acceptable,  the UAC core must generate a valid answer in the ACK and then send a BYE immediately. •Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive.

UAS Processing of the INVITE

•If the request is an INVITE that contains an Expires header field. When the timer fires before the UAS has generated a final response, a 487 response should be generated.

•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.

•The UAS can indicate  progress, accept, redirect, or reject the invitation.

Progress

•To prevent cancellation, the UAS must send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses.

The INVITE is Rejected

•A UAS rejecting an offer contained in an INVITE should return a 488 response. Such a response should include a Warning header field value explaining why the offer was rejected.

The INVITE is Accepted

•Note that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. •So it is necessary to periodically pass the response directly to the transport until the ACK arrives.(To ensure reliable delivery across these hops)

Modifying an Existing Session

•A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog must return a 500(Server Internal Error) response to the Second INVITE and must include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds.

•A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress must return a 491(Request Pending) response to received INVITE.

Transport

•A client that sends a request to a multicast address must add the maddr parameter to its Via header field value containing the destination multicast address. •Before a request is sent, the client transport must insert a value of the sent-by field into the Via header field. This field contains an IP address or host name, and port.

•When a response is received, and the value of the sent-by parameter in the top Via header field value does not correspond to a value that the client transport is configured to insert into requests, the response must be silently discarded. •When the server transport receives a request over any transport, it must examine the value of the sent-by parameter in the top Via header field value.

•If the host portion of the sent-by parameter contains a domain name, or if it contains an IP address that differ from the packet source address, the server must add a received parameter to that Via header field value. •This parameter must contain the source address from which the packet was received.

Note

•Each proxy uses the Via header field to determine where to send the response and removes its own address from the top.

•If the proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI  resolving to the hostname or IP address of the proxy.