sip
sip: the default transport protocol is UDP; sips: the default transport protocol is TCP. tcp defaults to 5060, tcp+tls5061; tcps5061.
Session Initiation Protocol (SIP), an application-layer control (signaling) protocol with one or more participants for creating, modifying, and terminating sessions.
User Agent UA: The user agent can send registration information, session invitations, and other requests to the proxy server.
Transaction: In a transaction, when the request is an INVITE (called an INVITE transaction), when the final response is not a 2xx response, the transaction also includes an ACK. If the reply is a 2xx reply, then the ACK is not considered part of the transaction.
Session Description Protocol (SDP): negotiation of conference details, such as codec, sampling rate, etc.
A transaction consists of 5 necessary parts: from , to , branch parameter of Via header , call-id and cseq The branch parameter is a unique transaction identifier .
Dialog : The combination of Call-ID , from-tag and to-tag can uniquely identify a dialog . A conversation contains at least one transaction.
Session : Only when the media negotiation is successful, the session can be established .
Conversations and transactions are at the signaling layer, while sessions are at the media transport layer.
The Call-ID of the same session ( dialogue ) window remains unchanged, but it is not necessarily a dialogue, because the to-tag may change; when 180 , the to-tag is filled, and when 100 is empty.
INVITE is the only way to establish a dialog in SIP
The header fields are briefly described as follows:
Via(v) contains the address information (pc33.atlanta.com) from which Alice wishes to receive the response to the request. Via also contains a branch parameter that identifies the transaction. The branches of the same transaction are the same. The received parameter is the address of the peer that sent the response
Max-Forwards limits the number of hops a request can make on the way to its destination. It contains an integer that is incremented at each jump point. If the Max-Forwards header field is 0, the request will be responded directly.
To(t) contains a display name (Bob) and a SIP or SIPS URI (sip:[email protected]), which is the destination address of the request. Display names are described in RFC2822 [3].
From(f) also contains a display name (Alice) and a SIP or SIPS URI (sip:[email protected]), which is the source address of the request. This header field has a tag parameter that contains a random string that the softphone adds to the URI. It is used for identification .
Call-ID(I) contains the globally unique identifier for the call, concatenated from a random string, softphone hostname or IP address. Together, To tag, From tag and Call-ID define a peer-to-peer SIP relationship between Alice and Bob, called a dialog.
A CSeq , or command sequence, consists of an integer and a method name. Within a session, the CSeq number is incremented with new requests, traditionally it is a sequence number.
Contact(m) contains a SIP or SIPS URI, which represents a direct route to contact Alice, consisting of the username in the absolute domain name (FQDN). When FQDN is selected, many end systems do not have registered domain names, so IP addresses are allowed. The Via header field tells other elements where to send responses, and the Contact header field tells other elements where to send requests later.
Content-Type (c) contains a description of the message body.
Content-Length(l) contains the octets (bytes) used to calculate the length of the message body.
To , From, Cseq, Call-ID, Max-Forwards and Via. These header fields are .
Attached:
Record-Route : The proxy always stays on the SIP signaling path and knows all the signaling interactions of the session. If not added, the proxy will no longer go through the invite.
Content-Encoding : Codec
Allow : set of allowed methods
Require : UAC (self) expects SIP extensions supported by UAS
Unsupported : Require options not supported by UAS
Accept : the message body type supported by self
Accept-Encoding : Encoding supported by self
Accept-Language : languages supported by self
Supported : Supported Require options
Route : The lr parameter of the routing set indicates that the element implements the specified routing mechanism, and no lr means strict routing ( 16.12.1 example )
Alert-Info : replace the ring tone
Retry-After: Prohibit request duration, such as 30s and try again
WWW-Authenticate : Unauthorized 401 for register authentication
Proxy-Authenticate: : Proxy authentication for 407 invite requests
Description of Content-Disposition :
| alert |
The message body is a custom ringtone to alert the user |
The SIP response consists of a three-digit code + a description phrase.
Every time the invite passes through a proxy server, a via routing address is added to the invite . When responding, each proxy uses the Via header field to decide where to send the response and removes its address from the top. ( There are three Via header field values here—one added by Alice's SIP phone, one added by the proxy server, and one added by the biloxi.com proxy.)
There are two phases of SDP message exchange: Alice sends an invite request message to Bob, and Bob returns a response message (183 or 200) to Alice. This two-phase exchange provides basic negotiation capabilities.
The 200 (OK) is routed back through the two proxy servers, and the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing both proxies . This is because the two endpoints already know each other's address from the Contact header field of the INVITE 200 (OK) exchange, so it is no longer necessary for the two agents to perform the query, and the two agents exit the call process. This completes the three-way INVITE/200/ACK handshake used to establish the SIP session.
Change media session characteristics during a session -- re-INVITE
Both Alice and Bob can change the media session characteristics during the session . Changes can be made by sending a re-INVITE reporting the new media description. Re-INVITE needs to mention an established conversation to let the other party know that it is modifying the existing conversation, not establishing a new one. The other side sends a 200 (OK) to accept the change. The requester responds with a 200 (OK) with an ACK. If the other party does not accept the change, he will send an error response, such as 488 (not accepted here), and the ACK is also received at this time. However, failure of the re-INVITE does not cause the existing session to fail - the session continues using the previously negotiated characteristics.
For example: after a session is established, new requests such as re-INVITE, BYE, etc. are sent point-to-point directly without going through a proxy.
The Record-Route proxy server always stays in the SIP signaling path -- the general session will no longer go through the proxy server after the session starts
Add to the INVITE a required routing header field, Record-Route , which contains the URI to resolve the proxy's hostname or IP address.
Call Stateful : An agent is call stateful if it retains the state of the dialog from the initial INVITE to the terminating BYE request.
The Record-Route header field in REGISTER requests and responses has no meaning.
SIP message
Messages consist of a start line, one or more header fields, a blank line marking the end of the header fields, and an optional message body.
generic-message = start-line
*message-header
CRLF
[ message-body ]
The start line, each message header line, and blank lines must be terminated with a carriage return line feed sequence (CRLF). Note: Empty lines are required even if there is no message body.
Request -- Request-Line
The Request-Line consists of a method name, a Request-URI and the protocol version separated by space (SP) characters.
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method : REGISTER for registering Contact information;
INVITE, ACK and CANCEL for session establishment;
BYE to terminate the session and OPTIONS to query server capabilities.
Response -- Status-Line
The Status-Line consists of the protocol version number, the digital Status-Code and the related textual phrase in turn.
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
1xx: informational - Interim response The request has been received, continue to process the request.
2xx: success - A successful response has been successfully received, understood and introduced to the action.
3xx: Redirection - Redirection In order to complete the call request, further action must be taken.
4xx: Client Error - Client Error The request has syntax errors or the server cannot execute the request.
5xx: Server Error - Server Error Unable to perform legitimate request.
6xx: GLOBAL FAILURE - No server could execute the request.
header field
Format: field-name: field-value
The same header fields can be combined into one: add each field value after the first one in turn. So order matters.
Header field values can be extended over multiple lines by preceding each additional line with a space (SP) or horizontal tab (HT).
UA behavior
UAC behavior: generate requests, send requests, process responses
UAC Behavior: Method Check: Allow header field prompts supported methods
Header check: header field not understood, ignore and continue with subsequent content
redirect server
When the redirecting server returns a 3xx response to a request, it fills in the optional address(es) in the Contact header field. The expires parameter of the Contact header field value can also indicate the life cycle of the Contact number.
Can be modified: transfer URI, transfer between tcp and udp
Cancel request CANCEL -- a request that takes a long time for the server to respond
Cancels the previous request sent by the client. It asks the UAS to stop processing the request and generate an error response for the request.
A UAS that receives a CANCEL request from an INVITE , but does not send a final response, MAY " stop ringing " and then send the INVITE a specific error code (a 487 ) .
CANCEL requests also do not contain a Require header field.
Note: The BYE of the call can only be sent after receiving the ACK of the INVITE . A CANCEL to a transaction cannot be sent until a provisional response 1xx has been obtained for the request .
Register REGISTER
Location service: registration server (establish mapping - location service front end), redirection server (query mapping - location service backend)
The registrar in the domain must be able to read and write data in the location service, and the proxy and redirection services in the domain must be able to read the same data.
If a Record-Route is included in a REGISTER request, the registrar MUST ignore the Record-Route header field.
REGISTER requests must have header fields: Request-URI, To, From, Call-ID, CSeq, Contact
Deleting a binding: The Expires header field is indicated by a value of "0", which immediately deletes the binding. When not configured, the default is 3600s
Fine-grained binding: Before Expires ends, issue a REGISTER request for each binding to update Expires.
Fetching Bindings: The 200 (OK) response from the registrar contains a series of Contact headers listing all current bindings.
Min-Expires header field - indicates the minimum timeout interval that the registration server wants to prevent too frequent registration updates
Query capability OPTIONS
OPTIONS allows UAs to query the capabilities of other UAs and proxy servers. Return the Supported header field
The Accept header field specifies the type of message body that the UAC expects to receive in the response. The default is application/sdp.
The Allow , Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD appear in 200 (OK) responses to OPTIONS requests.
Dialogs
A dialog, represented as a point-to-point SIP relationship between two user agents (UAs) that lasts for a period of time. Conversations make it easier to deliver messages sequentially between user agents and to route requests correctly between two user agents. A dialog can be considered as a context for interpretation of SIP messages. A dialogue is marked with a dialog ID in the UA participating in the dialogue. This dialog ID is composed of Call-ID, a local tag and a remote tag, that is, the combination of the three values of Call-ID, from-tag and to-tag Able to uniquely identify a conversation.
1 ) For UAC, the value of Call-ID in the dialog ID will be filled in the Call-ID field in the message, the remote tag will be placed in the tag parameter of To in the message, and the local tag will be placed in the tag parameter of From .
2 ) For UAS, the Call-ID value of the dialog ID is placed in the Call-ID header field of the message, the remote tag is placed in the tag of the From header field, and the local tag is placed in the tag parameter of the To header field
A conversation ID consists of a Call-ID value, a local tag, and a remote tag.
| UAC |
UAS |
|
| local serial number |
The sequence number value of the response's CSeq header field |
NULL |
| remote serial number |
NULL |
Request CSeq header field |
| dialog ID |
Requested Call-ID |
Requested Call-ID value |
| local label |
From field in the request |
To field in the response |
| remote tag |
To field in the response |
From field in the request |
If the serial number value of the request received by the UAS is lower than the remote serial number value, the request is out of order and must be rejected, returning a 500 (internal server error) response.
The serial number value of the request received by the UAS is higher than the remote serial number value, and the requests are in order. The UAS sets the Remote Sequence Number to the value of the CSeq header field of the request.
conversation
INVITE 。。。 1XX 。。。2XX 。。。ACK
When 2XX responds, a session and dialogue are established.
A session is a collection of associations among all participants and media streams between them in a communication process. A session can be established only after successful media negotiation.
INVITE initiates a session
Allow : methods that can be called within the dialog
Supported : supported extensions
Accept : Accepted message types, such as text, json, xml, etc.
Expires : Validity timeout to generate a cancel request
A successful INVITE request (see Section 13) establishes both a dialogue and a call-answer session between two user agents.
Call/Answer Mode: The call indicates the desired communication method (audio, video, game), the parameters of these methods (eg, encoding type) and the address of the receiving transponder media. "Response", which indicates which communication methods are accepted, the parameters used for these methods, and the media type of the accepting caller. As described in the SDP session. INVITE . . . 2XX (or 183)
1xx Responses , provisional responses to INVITE requests, can create "early dialogs". When 2XX responds, a dialog and session are established. The bag behind the To field of 2XX is the unique identifier of the dialog, which is used to distinguish when there are multiple invites. Both 1xx and 2xx responses create a dialog, and if this response completes a call/answer exchange, it also creates a session.
A 3xx response MAY contain one or more Contact header fields - providing a new address at which the callee can be reached.
re-INVITE modify session – ip port media stream
call on hold
Session hold means that the user who is talking can temporarily interrupt the original call, make a new call, and keep in touch with the original call at the same time; when it is necessary to return the original call, put the new call on hold, and then continue Talk to the original caller, that is, you can select and switch between the two calls by operating the buttons, and you can also end the call with them separately or at the same time. The difference between the session hold service and the basic call is that it allows us to have two connected sessions and switch back and forth between the two sessions any number of times.
Hold, the direction of the media stream is sendonly. The normal call is sendrecv
BYE end session
The effect of a caller 's non-2xx final response to INVITE in a dialog is that the caller uses CANCEL . Such as calling 603, 487 and so on.
Hangup: For the caller UA , if the initial INVITE did not create a final response (1xx only), then hangup means a CANCEL request; for all confirmed dialogs after the final response, hangup means BYE. For the callee UA, generally speaking, hanging up means BYE.
acting
Process for new requests:
- confirmation request
- Preprocess routing information
- Determine request target
- Forward requests to each target
- process all responses
See the 16.12.1 example of RFC3261 for details
*** Affair***
SIP is a transactional protocol: interactions between components occur in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to this request (including zero or more provisional responses and one or more final responses).
Transaction Matching: Unique Identification: The branch parameter in the Via header field. Or the method of Cseq is the same, such as the branch parameters of CANCEL are different.
In particular, when the request in a transaction is an INVITE (called an INVITE transaction), the transaction includes an ACK only if the final response is not a 2xx response. If the final response is a 2xx, then the ACK should not be considered part of the transaction.
Retransmission mechanism: After INVITE, Unreliable Transmission (UDP) starts the retransmission mechanism. After receiving 1XX, the client stops retransmitting INVITE and waits for further response. For unreliable transmission, the server's response is also actively retransmitted periodically , and reliable transmission (TCP) does not retransmit. The corresponding client transaction sends an ACK for each final response to end the response retransmission . The server TU transmits the latest response to the transport layer for retransmission, instead of sending it reliably by the transaction layer.
T1/T2
T1 : is the evaluation of the transaction round-trip delay (RTT) time between the server and the client. T1 default 500ms
T2 : Maximum retransmission interval for non- INVITE requests and INVITE responses . T2 defaults to 4s, T4 defaults to 5s
For retransmission, after a total of 64T1=32 seconds, the registration request will be sent again from T1 until it succeeds. Send a total of 7 retransmission requests , first, 0.5, 1, 2, 4x7
Scenario: After the SIP terminal sends 200 OK, the creation of the media begins, and the RTP voice stream starts. In fact, the SIP terminal may not have received the ACK message, so the party that did not receive the message sent it in about 30 seconds. A BYE message.
When the message is too long , the message is sent using TCP instead of UDP.
INVITE transaction
(not 2XX final response) -- ACK by TU - Transaction - Transport Layer
C_TU： INVITE（calling） -> 1XX（proceeding）-> 非2XX（completed）==== >（Terminated）
C transaction: calling (initiating client transaction) in progress completed terminated (client transaction is destroyed)
Timer A, B 32s Stop A, B Timer D 32s D triggers to terminated state
S_TU： INVITE、1XX (proceeding) -> 非2XX（completed）-> ACK(confirmed) ==== >（Terminated）
S transaction: proceed complete confirm terminate (server transaction is destroyed)
Timer G MIN(n ＊T1,T2) , H32s stop G , H , start I (T4) I trigger
(2XX Final Response No Timer) -- ACK by TU ---- - Transport Layer
C_TU： INVITE -> 1XX -> 2XX （Terminated）
C_transaction : Calling (initiating client transaction) in progress Terminate (client transaction is destroyed)
S_TU： INVITE, 1XX(proceeding) -> 2XX（Terminated）
S_transaction : Calling (creating server transaction) terminating (server transaction being destroyed)
Non-INVITE transactions
C_TU ： REQ（trying） -> 1XX（proceeding）-> 2-6XX（completed）==== >（Terminated）
C_transaction : attempt (initiate client transaction) proceed complete abort (client transaction is destroyed)
Timer E MIN(n ＊T1, T2) , F32s 1xx E, F is still valid EF stops, starts K (T4=5s) K triggers to end state
S_TU： REQ (trying) -> 1XX(proceeding) -> 2-6XX（completed）==== >（Terminated）
S_transaction : Attempt (establish server-side transaction) proceed complete terminate (server-side transaction is destroyed)
Timer J 32s J trigger terminated
Note: Both INVITE and 1XX can receive 2XX directly
The To header field in the ACK MUST be equal to the To header field in the response being acknowledged, but is often different from the To header field in the original request due to the tagging parameter it adds.
Non-INVITE client transaction
ACKs are not used for non-INVITE transactions. They are simple request-response interactions. Such as option, cancel, BYE
For non-INVITE transactions, the server transaction will retransmit the last response it sent only when it receives a retransmission request. This response can be a provisional response or a final response. Final response, stop transaction retransmission request . This is why requests continue to be retransmitted even after provisional responses: they are to ensure reliable delivery of final responses.
SIP sum SIP URI
Format: sip:user:password@host:port;uri-parameters?headers
Note: Strings need to be escaped
tcp defaults to 5060, tcp+tls5061; tcps5061. Note: But sip:user@host is not equal to sip:user@host:5060.
For specific comparison examples, refer to 19.1.3 URI Comparison
call tag callid from-tag to-tag
invite： callid from-tag
180： callid from-tag to-tag
sip signaling example registration , session establishment see 24 examples
Safety
TLS (TCP) -- provides security at the network and transport layers
HTTP Authentication -- Challenge Digest Authentication Mode
S/MME (TCP) -- provides end-to-end integrity and confidentiality for the message body, and can also provide mutual authentication
Attached:
Session Invitation Topology Map
sip redirect
sip transaction
sip conversation
sip trapezoidal
register registration message flow
invite message flow
bye message flow
Event subscription and notification subscribe, notify
After the subscribe is successful, there is at least one notify to ensure full duplex, followed by the push notification event.
instant message message
Tripartite Meeting
When inviting alice for the second time, contact carries the function label tag-"isfocus", indicating that Bob is a conference processing center.
SIP network elements
( 1 ) SIP User Agent ( SIP Terminal )
SIP User Agent (UA) is an end-user device used to create and manage SIP sessions such as mobile phones, multimedia handheld devices, PCs, and PDAs. User agent clients send messages, and user agent servers respond to messages.
( 2 ) SIP Registrar
The SIP Registrar is a database containing the locations of all user agents in the domain. In SIP communication, these servers retrieve the IP address and other relevant information of the participating party and send it to the SIP proxy server.
( 3 ) SIP proxy server
The SIP proxy server accepts the session request of the SIP UA and queries the SIP registration server to obtain the address information of the recipient UA. It then forwards the session invitation information directly to the recipient UA (if it is on the same domain) or to a proxy server (if the UA is on another domain).
( 4 ) SIP redirect server
A SIP redirect server allows a SIP proxy server to direct SIP session invitation messages to external domains. The SIP redirect server can be on the same hardware as the SIP registrar and SIP proxy server.
sip protocol structure
The logical hierarchy of SIP is as follows from low to high:
Grammar and coding layer :
Encoding uses BNF (Backus-Naur Form)
transport layer:
It specifies how the client sends a request and receives a response, and how the server receives a request and sends a response. All SIP elements include a transport layer.
Transaction layer (state machine and timer to achieve retransmission):
Transactions are a fundamental part of the SIP protocol. A transaction is a request sent by the client transaction layer using the transport layer , and all responses returned by the server transaction layer. The transaction layer handles the retransmission of the application layer, matches the corresponding response to the request , and the application layer times out. Stateful proxies contain a transaction layer, and stateless proxies do not contain a transaction layer. The transaction layer has a client component (called a client transaction) and a server component (called a server transaction), both represented by finite state machines, to handle specific requests.
Transaction User (TU):
Except stateless proxy, every SIP entity is a transaction user TU. When a transaction user wants to send a request, it creates a client transaction instance (transaction instance), and sends the request together with the destination IP address and port. A TU that creates a client transaction can also request to cancel the transaction via CANCEL. A CANCEL request contains its own transaction and also mentions the transaction that needs to be canceled.
SIP elements are UAC, UAS, stateless and stateful proxy, and registrar. Both contain a core (core) to distinguish, except for the stateless agent, the rest of the cores are TU. It can be understood that the core of a UA of a SIP entity is a TU.
Dialogue is an end-to-end sip relationship between two ua for a period of time. The ACK for the 2xx response is directly delivered by the TU to the transport layer for transmission without going through the transaction layer.