noiile
•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)
•The initial Request-URI of the message should be set to the value of the URI in the To Field.(except the REGISTER method)
•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
•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
•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
•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.
•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.
•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.
•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
•Require
•Proxy-Require
•These fields contain a list of option tags, that are understood by the UAs or Proxy.
•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.
•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.
•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.
•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
•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.
•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.
•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.
•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.
•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.
•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.
•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.
•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).
•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.
•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”.
•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.
•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.
•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.
•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.
•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.
•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.
•Dialogs are created through the generation of non-failure responses(2xx and 101-199 with a To tag) to requests(INVITE) with specific methods.
•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.
•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.
•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.
•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.