In a conversation, there are other correlations that will be sent. A conversation is an end-to-end sip relationship between two users that lasts a certain amount of time. The dialog process requires that the information between the two user agents be ordered and that the request be routed properly. In this specification, only invite requests can be used to establish a session. When a UAC makes a request in a conversation, it follows not only the general UAC rules described in section 8th but also the request rules in the dialog. Section 12th describes the dialogue and discusses the creation and maintenance of the dialog, as well as creating a request in the dialog.
The most important approach in SIP is the Invite method, which is used to create session usage among different participants. A session consists of a group of participants, a stream of media used to communicate between them. Section 13th describes the process of creating and initializing these sessions, and creating one or a set of dialogs. The 14th section describes the use of invite requests in dialogs to change the properties of a session. Finally, the 15th section describes how to terminate a session.
Sections 8th, 10, 11, 12, 13, 14, and 15 describe the complete UA core (section 9th describes cancellation, which is used in the UA core and the agent core). The 16th section speaks of proxy servers, which are used for message routing between two UA.
6, the definition of the agreement
The following ranking is of additional significance to sip:
Address-of-record: Record address. A Address-of-record (AOR) is a sip or SIPs URI that points to a host with a location service that maps the URI to the URI of the user's real physical location. Typically, the locator server is established by registering the service. A AOR is often considered a "public address" for a user.
Back-to-back useragent: A back-to-back user agent (B2BUA) is a logical entity that receives and processes requests just like a user Proxy server (UAS). To determine how to answer a request, B2bua works like UAC and makes a request. But unlike a proxy server, it maintains the state of the conversation and participates in every request in a conversation that has been established. Because it is a direct concatenation of UAC and UAS, there is no need to have an additional definition for him.
Call: Calling, a call is an informal term, which refers to a number of communication behaviors between endpoints, often used to create multimedia conversations.
Call Leg: The alias of the dialog, not used in this specification.
Call Stateful: If a proxy server (proxy) holds the state of a dialog (from the beginning invite to the bye of the end of the conversation), then the proxy server is requested to be stateful. A proxy server that requests a stateful (call stateful) must also be a transaction stateful, but the state of the transaction is not necessarily a request stateful.
Client: Clients. A client is an arbitrary network element that emits SIP requests and receives SIP responses. Clients may or may not interact with people. Both the User Agent client (UAC) and the proxy server are clients.
Conference: A multimedia session that contains multiple participants (see later).
Core: Cores. The core defines a specific category of SIP entities. For example, a stateful and stateless proxy server, a user agent or a registered server (registrar), is defined. All the cores, except stateless proxy servers, are transactional users.
Dialog: Dialogue, a conversation is an end-to-end sip relationship between two UA for a period of time. A conversation is created by a SIP message, like a 2xx response to a invite request. We use the call identifier,local tag (local tag), remote tag (the other tag) to mark a dialogue, a dialogue in RFC 2543 is officially called calls LEG.
Downstream: It is the direction of message delivery in a transaction. It refers specifically to the direction of the request flow from UAC to UAS,
Final Response: End response. A response to a terminal SIP transaction, as opposed to a temporary response in the middle of a transaction. All 2XX,3XX,4XX,5XX,6XX responses are end responses.
Header: header. The header field is the part of the SIP message header that describes the SIP message information. It consists of a heap of header field fields.
Header field: Header field fields. The header field is the field in the SIP Message header field. A Head field field can be composed of multiple header field characters field. A header domain field consists of a header domain name and (0 or more) header field values. The multi-head field value is segmented with ', '. Some header field fields can have only a single value, such as result fields (results), which can have only one value.
Header field value: Header field values. A header field value is a single value that can have 0 or more header field values.
Home Domain: Host. A host that provides SIP services. Generally refers to the host of the URI in the record address indicated in the registration service.
Informational Response: Prompt answer. The same as a temporary answer.
Initiator, calling party, Caller: the side of the initial session (and dialogue) with invite. A caller begins with a invite request to establish a conversation, which is always the role for the end of the conversation.
Invitation: A invite request.
Invitee,invited user,called Party, callee: called. The party that received the invite request and established the session. A called party from receiving invite request, to terminate invite established dialogue end, is called the callee.
Location Service: Positioning services. The location service is used for SIP forwarding or proxy servers to determine where the caller might be. It contains a table that is bound to Address-of-record, and the callee may have 0 or more records. A bound record can be added and deleted through multiple channels; This specification defines a register method to update the binding table.
Loop: Loop. When the request arrives at a proxy server, the proxy server forwards the request, and when the request arrives at the same proxy server, it is called a loop. When the second time arrives, the Request-uri contains the last arrival information, and there is nothing to change the forwarding strategy, which causes the request to be forwarded back again. The loop request is incorrect, so the handler needs to detect and prevent loop requests appearing in the protocol.
Loose Routing: Lost route. The proxy server will lose routing in the following situations.
A Proxy is said to being loose routing if it follows the procedures defined in this specification for processing of the Route Header field. These procedures separate the destination of the request (present in the Request-uri) from the set of proxies that need to Be visited along the way (present in the Route header field). A proxy compliant to this mechanisms is also known as a loose router.
Message: Messages. The protocol data that is transmitted between SIP elements is the message. SIP messages can be either a request or a response.
Method: Methods. The method is the primary function of the server request processing. The method is to request that the message be carried by itself. The typical approach is invite and bye.
Outbound Proxy: External proxy server. A proxy server receives a request from a client, even if it is not a server determined by Request_uri. Typically, a UA configures an external proxy server manually, or it can be configured automatically via an automatically configured protocol.
Parallel Search: Parallel searches. In a parallel search scenario, a proxy server initiates a request to a place where multiple users may exist and waits for a response. Unlike a serial search, a parallel search does not wait for the previous request to reply back to the next search, but one after another to initiate the search request.
Provisional Response: temporary response. The server is used to flag the answer that it is processing, but this answer does not end a SIP transaction. The 1xx answer is temporary, and other responses mark the end of the transaction.
Proxy,proxy server: Proxy, proxy server. An intermediate entity. It itself serves as the client as well as the service side, providing the requested forwarding service for other clients. A proxy server first provides routing services, which means that the request is sent to a more "near" target user. A proxy server is useful for certain enforcement policies (for example, to confirm whether a user is allowed to establish a call, etc.). A proxy server translation and, if necessary, rewrite the request message before forwarding.
Recursion: Loops, recursion. A client who, when responding to a request, produces a new URI request to the contract header domain, falls into recursion in the 3xx response. A client recurses on a 3xx response as it generates a new request to one or more of the "URIs in" Contact header field In the response.
Redirect server: Redirecting servers. A redirect server is a UAS server that generates a 3xx answer, instructing the client to connect to another URI.
Registrar: Clerk. A Registrar (registration server) is a receiving register request server. He puts the requested information on the locator server, which makes it easy for the locator server to find the location information.
Regular Transaction: General transactions. A transaction that does not contain Invite,ack or Cancel methods is a regular transaction.
Request: Requests. A sip of information sent by a client to a service to perform a specific function.
Response: Answer. A SIP information sent by the server to the client. Used to flag the request processing from the client to the service side.
Ringback: Back ring tone. The ring-back tone is a signal tone. A signal is given to the caller that the caller is ringing (ringing).
Route set: Routing set. A routing set is a sip or sips URI in order. These URIs describe the list of proxies that must go through to pass a request. A routing set can be adaptive because the header contains either Record-route (record routing) or dependency configuration.
Server: Servers. A server is a network element that receives the request and processes the request and sends a response to the requesting party. Typically, the server is a proxy server (proxies), a user proxy server (users agent servers), redirecting servers, registering servers.
Sequential search: Sequential lookup. In sequential lookups, the proxy server sequentially tries to contact the address, and must wait until the previous request has an end answer before processing the next one. A 2xx or 6XX series final answer always ends with an order lookup.
Session: Sessions. According to the SDP description: "A multimedia session is a collection of multimedia senders and recipients, and includes data flow between sender and receiver." A multimedia conference is a typical multimedia session. (RFC 2327[1]) (a session is ordered in SDP can be one or more RTP Sessino). In the definition, a called party can be invited multiple times, being invited by different callers to the same session. In SDP, a session can be defined by a set of strings for the SDP user name, sessions ID, network type, address type, and address element.
SIP transaction: A SIP transaction is an event that occurs at the client and service side, including the end-to-end response to the client from the first client sent to the service, to the last (non 1xx) server. If the request is a invite request and the termination answer is a non-2xx answer, then the transaction also includes an ACK to answer the server. The ACK response to the 2XX response to the invite request is an independent transaction.
Spiral: Backtracking. A backtracking is a SIP request that is routed to a proxy and forwarded, but is routed back to the proxy, but unlike the loop (recursive), the header of the requested packet, which is routed back, contains the part of the request package that is different from the original request. Makes the routing forwarding of this proxy decision different from the last. Typically, this is to say that the requested Request-uri is different from the last Request_uri. A backtracking is not a fault, unlike loops (loop loops). This is usually caused by call forwarding (called forwarding). A user calls joe@example.com. The example.com Proxy server forwards requests to Joe's PC, and Joe's PC call is transferred to bob@example.com. This request is forwarded back to the example.com proxy server. But this is not a loop (loop). Because the destination address of the request becomes another user, this is backtracking and is a legitimate case.
Stateful proxies: Stateful proxy servers. Logically, a stateful proxy server is the process of processing a request, maintaining a client and server-side transaction state machine defined by this specification. It is also a transaction and status Proxy server (transaction stateful proxy). The specific stateful proxy is defined in section 16th. One (transaction) stateful proxy server is not the same as a call stateful proxy.
Stateless proxy: Stateless agent server. Logically, stateless proxy servers do not maintain client and service-side transaction state machines in processing requests. A stateless proxy server forwards each received request and each received response directly.
Strict Routing: Strict routing. Routing rules if the RFC2543 protocol is reviewed (and many prior work in progress the This RFC) is a strict route. Under this rule, if you include the route field in the header, the proxy server deletes the Request_uri domain content. This document does not require strict routing, and this document only requires loose routing. A proxy server that supports strict routing is also called a strict router.
Target Refresh Request: The destination refreshes requests. A target Refresh request is a request that is made in a conversation to change the target of a conversation.
Transaction User (TU): Transaction users. The protocol layer above the transaction layer. Tu includes the UAC core, UAS cores, and proxy core.
Upstream: Upstream flow. The direction in which a message flows in a transaction. It refers to the direction in which messages are sent by the user Proxy Server (UAS) to the User Agent client (UAC).
Url-encoded: A string of characters encoded according to the rfc2396-2.4 section.
User Agent Client (UAC): Users proxy clients. The user agent client is a logical concept, he creates a new request, and sends the request with the client transaction state machine. The UAC role exists only in transactions. In other words, UAC is a small piece of code that initializes a request and follows the rules of UAC in a transaction. If it next receives a request, then in that transaction it is acting as a UAS to process the request.
UAC Core:uac Core. A collection of features that are implemented by UAC on top of the transaction and transport layers.
User Agent Server (UAS): Users proxy Server. UAS is a logical entity that responds to SIP requests. Answer accept, reject, or forward the corresponding request. The UAS role exists in the transaction. In other words, it is a small piece of software that responds to a request and exists as a UAS in a transaction. If he makes a request, he exists as UAC in the transaction.
UAS Core:uas Core. The transaction and transport layers of IQ are UAS implemented in a set of functions.
The User Agent (UA). The concept of a logical entity that includes UAC and UAS.
UAC and UAS, like proxy servers and forwarding servers, are defined on the principle of a transaction by transaction (serial transaction processing). For example, when an initialization invite request is issued, UA Initializes a call action as UAC, and when a bye request is received from the callee, UA acts as a UAS response. Similarly, the same code can handle a request as a proxy server and a redirect server for another request.
Proxy,location,registrar servers are logical entities and may be implemented as a single application in their implementations.
7. SIP message:
The SIP protocol is a text-based protocol using the UTF-8 character set (Rfc2279[7]).
A SIP message can be either a request from the client to the server or a response from the server to the client.
The request (7.1) or the reply (7.2) message is based on the RFC2822 format, even if the character set is different from the syntax details. (SIP allows the header domain to be not standard RFC2822 Baotou domain). Both types of messages are composed of a starting line, one or more header domains, and an optional message in Chinese.
General message = start line
* Message Header
CRLF
[Message body]
Start Row = Request Line/status line
The start row, each header row, blank line, must be made up of a carriage return wrap (CRLF). Even if the message is not in Chinese, there must be a blank line to follow.
In addition to the differences in character sets, many SIP messages and header fields have the same format as http/1.1. We do not repeat its syntax and semantics here, we use [HX. Y] To mark the description of the x.y section of the http/1.1 specification (Rfc2616[8]).
SIP is not an HTTP superset or extension.
7. 1 requests
SIP requests are differentiated according to the Request-line in the starting row. A request_line contains the method name, Request-uri, with a single space (SP)-separated protocol version.
The request-line is ended by CRLF. In addition to being used as a line end sign, CR or LF is not allowed to appear elsewhere. Linear whitespace is not allowed in other domains (liner whitespace LWS)
Request-line = Method sp Request-uri SP sip-version CRLF
Method: This specification stipulates 6 methods: Register is used to enlist contact information, Invite,ack,cancel is used to establish sessions, bye is used to end sessions, and options are used to query server load. SIP extensions, Standard RFCs append methods that may contain extensions.
Request-uri:request-uri is a sip or sips URI, which they are described in section 19.1. It can also be a generic URI (RFC 2396[5]). It flags the address of the user or service used by the request. Request-uri prohibits the inclusion of whitespace characters or control characters, and is prohibited by "<>".
SIP elements can support the Request-uris specified in addition to sip or sips. such as "tel" uri mode (RFC 2806[9]). SIP elements can use their own mechanisms to convert Non-sip URIs to the SIP uri,sips URI or other format URI.
Sip-version: Both the request and answer messages contain the currently used SIP version, which follows [H3.1] (similar to HTTP with SIP substitution, sip/2.0 replace http/1.1), version dependent, upgrade version number. An application, the SIP message emitted must contain the sip-version "sip/2.0". This SIP version string is case-insensitive, but uppercase must be sent in the implementation. \ grateful
Unlike Http/1.1,sip, the version number is treated as a text string. In implementation, this should not be different.
7. 2 Answer
The difference between a SIP response and a SIP request is whether a status-line is included in the Start-line. A status-line is a version string of a protocol before a status-code expressed by a number, separated by a single SP (space) between each element.
CR/LF is not allowed to appear in other places other than the last used as a closing sign.
Status-line = sip-version sp Status-code sp reasong-phrase CRLF
The Status-code is a 3-bit numeric result Code that is used to flag the processing of a request. Reason-phrase is a brief description of the Status-code. Status-code is intended to be used automatically, but reason-phrase is used for the user to see. A client does not require that this reason-phrase be shown or interpreted. This document recommends the output of this reason-phrase, in which other text can be selected, such as the appropriate language specified in the request header.
The first digit of the status-code represents the type of answer. The next two digits are not used for classification. For this reason, any status code in the 100 to 199 can be collectively called a "1xx response", similar, in 200 to 299 can be called a bit "2xx answer", and so on. SIP/2.0 allows 6 types of responses:
1XX: Temporary answer-request has been received, processing this request.
2XX: Successfully processed-the request was successfully received and the request was processed correctly.
3XX: Redirect-additional operations are required to complete this request, and this request is forwarded to another server for processing.
4XX: Client Error-The request contains an incorrect format or cannot be completed on this server.
5XX: Server error-the server cannot properly handle this apparently legitimate request.
6XX: Global error-The request cannot be processed by any server.
Section 21 defines a detailed code description.
7.3 Header Field
The SIP header and HTTP header fields are both syntactically and semantically similar. In particular, the SIP header domain follows [H4.2] 's definition of the syntax of the header, and follows the rules of the Extended header field of multiple lines. (the latter is specified in HTTP with implicit whitespace and folding). This specification follows RFC2234[10] and takes clear whitespace and encapsulation as intrinsic grammatical rules.
[H4.2] also defines a multiple-head field with the same domain name, whose value is a comma-separated list that can be merged into a header field. This also applies to sip, but the details are slightly different because the syntax is different. In fact, the header syntax for any SIP is based on the following paradigm:
Header = "Header-name" Hcolon header-value * (COMMA header-value)
This allows merging in a multiple-head field with the same domain name into a single header field separated by commas. The Contact header field allows a comma-delimited list, except when the field value is "*".
7.3.1 Header field format.
The header field follows the common header field format defined in section 2.2 of RFC2822. Each header field consists of a domain name plus a colon (":") and a field value.
Field-name:field-value
The regular syntax for message headers is described in section 25.
In the message header, there is an arbitrary number of whitespace allowed at the left and right of the colon, but in the implementation it is recommended that you avoid spaces between the domain name and the colon, and that a single space (SP) should be used between the colon and the value.
Subject:lunch
Subject:lunch
Subject:lunch
Subject:lunch
So the above are all legal and equal, but the last one is what we recommend.
The header field can be extended to multiple lines, as long as it starts with at least one SP or the Horizontal tab (HT) at the front of each additional line. This multiline header field ends at the end of the line and the blank SP (or HT) before the next row is considered a single SP character. So, the example below is equal:
SUBJECT:I know You "re there, pick up the" phone and talk to me!
Subject:i know you ' re there,
Pick up the phone,
and talk to me!
The relative order of the different domain names in the header field has no meaning. Nonetheless, we strongly recommend that routing-related domains (via,route,record-route,proxy-require,max-forwards,proxy-authorization, and so on) be placed at the front of the message header, This can increase the speed of processing. The order between domains of the same domain name is very important. Only when the domain value of a single header field is a comma-delimited list can it be expressed as a multiple-head field of the same domain name (that is, if you follow the syntax of the 7.3 definition). That means that you must be able to change the representation of the same domain name into a pair of "domain values" without changing the message semantics, which is to increment the field values of each field in order, and divide the field values by commas. There are several exceptions to this rule, namely Www-authenticate,authorization,proxy-authenticate, and Proxy-authorization header fields. Multiple-header field rows can appear in message headers, but because their syntax does not conform to the common format defined in 7.3, they cannot be merged into a single header field row.
On implementation, you must be able to handle the case of multiple-head field rows, and you must be able to handle the merged single-head field rows separated by commas.
The following groups of header fields are equal:
Route: <sip:alice@atlanta.com>
Subject:lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
The format of each header field value is dependent on its header domain name. He can be any sequence of text-utf8 characters, or it can be a combination of spaces, markers, delimiters, quotes around strings. Many header fields are shipped back with a common field value format. This field value format is a combination of the parameter names and parameter values separated by semicolons:
Field-name:field-value * (;p arameter-name=parameter-value)
Although there can be any number of parameter-name/parameter-value pairs in a field value, there is no way to allow the presence of the same parameter-name (uniqueness). In addition to the header fields that are specifically pointed out, domain names, field values, parameter name Parameter-value in the header field are case-insensitive. Tag words are always case-insensitive and grateful. Unless specifically specified, the string of quotation marks is case sensitive. For example:
Contact: <sip:alice@atlanta.com>;expires=3600
And
Contact: <sip:alice@atlanta.com>; expires=3600
Same.
Content-disposition:session;handling=optional
And
Content-disposition:session; Handling=optional
Same.
The two header fields below are not the same:
warning:370 Devnull "Choose a bigger pipe"
warning:370 devnull "CHOOSE A bigger PIPE"
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
