1.Basics of SIP protocol
Session Initiation Protocol is a signaling protocol that controls the initiation, modification, and termination of interactive multimedia sessions. It was defined in RFC 2543 by the IETF (Internet Engineering Task Force), which was first released in March 1999. Later, a new standard RFC 3261 was released in June 2002. In addition, there are many related or extended RFCs based on SIP, such as RFC 4566 about SDP, RFC 4579 about conferences, etc.
First of all, let’s take a look at the basic knowledge and basic concepts in the SIP protocol. In order to facilitate understanding, we will explain it in comparison with the HTTP protocol that you may be more familiar with.
2.HTTP and SIP protocol basics
SIP is a text-based protocol, similar to HTTP and SMTP. Let’s compare a simple set of HTTP requests with SIP requests.
HTTP:
GET /index.html HTTP/1.1
SIP:
INVITE sip:seven@freeswitch.org.cn SIP/2.0
The two are similar. The request consists of three parts: in the HTTP request, GET specifies an action to obtain the resource (file), /index.html is the address of the resource, and finally HTTP/1.1 is the protocol version number; in SIP, INVITE means to initiate a call request, seven@freeswitch.org.cn is the requested address, also known as SIP URI or AOR (Adress of Record, the user’s public address), and the third part of SIP/2.0 is also the version number. Among them, the SIP URI is similar to an email address, and its format is “protocol:name@host”. The “protocol” in the SIP URI format here corresponds to HTTP and HTTPS, and there are also two types: SIP and SIPS (the latter is encrypted, such as sips:seven@freeswitch.org.cn); the “name” can be a string of numbers The phone number can also be a name represented by letters; and the “host” can be a domain name or an IP address.
3. Basic concepts and related elements of SIP
SIP is a peer-to-peer protocol, similar to P2P. It is different from HTTP in that it does not have a client-server structure; nor does it require a central switch like traditional telephone calls. It can communicate without a server, as long as both communicating parties know each other’s address (or only One party only needs to know the address of the other party), which is called point-to-point communication. UA is a logical entity that initiates or responds to SIP processing in the SIP network. UA is stateful, that is, it maintains the state of the session (or conversation). There are two types of UA: one is UAC (UA Client), which is the party that initiates the SIP request, and the other is UAS called the registration server. There is also a special UA called Back-to-Back UA (B2BUA). It should be pointed out that RFC 3261 does not actually define the function of B2BUA. It is just a series connection of a pair of UAS and UAC. FreeSWITCH is a typical B2BUA. In addition, there is a concept called the Session Border Controller (SBC). It is mainly located at the boundary of a bunch of SIP servers and is used to hide the topology of internal servers and resist external attacks. The SBC may be a proxy server or a B2BUA. Its application location and topology are shown in Figure 1-1.
Figure 1-1 SBC Schematic diagram
4. SIP registration
Below we use the real registration process to explain.
recv 584 bytes from udp/[192.168.4.4]:5090 at 12:30:57.916812:
01 REGISTER sip:192.168.4.4;transport=UDP SIP/2.0
02 Via: SIP/2.0/UDP 192.168.4.4:5090;branch=z9hG4bK-d8754z-d9ed3bbae47e568b-1—d8754z-;rport 03 Max-Forwards: 70
04 Contact: sip:Alice@192.168.4.4:5090;rinstance=d42207a765c0626b;transport=UDP
05 To: sip:Alice@192.168.4.4;transport=UDP
06 From: sip:Alice@192.168.4.4;transport=UDP;tag=9c709222 07 Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
08 CSeq: 1 REGISTER
09 Expires: 3600
10 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE 11 User-Agent: Zoiper rev.5415
12 Allow-Events: presence
13 Content-Length: 0
·REGISTER on line 1 indicates that this is a registration message.
·The Via in line 2 is the message routing of SIP. If SIP is forwarded through many proxy servers, there will be multiple Via records.
·In line 3, Max-forwards indicates the maximum number of times the message can be forwarded, mainly to prevent an infinite loop.
·In line 4, Contact is Alice’s contact address, which is equivalent to Alice’s home address. In this example, FreeSWITCH should be able to find her at port 5090 on the machine 192.168.4.4.
·To and From in lines 5 and 6 indicate registration as Alice.
·Line 7, Call-ID is the identifier of this SIP session (Session).
· Line 8, CSeq is a sequence number. Since UDP is an unreliable protocol, packets may be lost on unreliable networks, so some packets need to be retransmitted. This sequence number can prevent message duplication caused by retransmission.
·Line 9, Expires indicates the validity period of this registration, in seconds. In this example, Alice’s registration information will expire after one hour, and she should register with FreeSWITCH again within half an hour to prevent FreeSWITCH from “forgetting” her. In fact, most UA implementations will resend the registration request within tens of seconds, which helps maintain the connection in a NAT network.
·Line 10, Allow describes the functions that Alice’s UA can support. Some UAs have rich functions, while some UAs only have limited functions.
·Line 11, User-Agent is the UA model.
·Line 12, Allow-Events specifies which event notifications she allows.
·Line 13, Content-Length is the length of the message body (Body). Here there is only the message header (Header) and no message body, so the length is 0.
FreeSWITCH requires identity verification before being allowed to register in SIP. It did not invent a new authentication method, but uses the existing HTTP Digest method for authentication. Send back (send, send) 401 response message, the message content is as follows:
send 664 bytes to udp/[192.168.4.4]:5090 at 12:30:57.919364:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.4.4:5090;
branch=z9hG4bK-d8754z-d9ed3bbae47e568b-1—d8754z-;rport=5090 From: sip:Alice@192.168.4.4;transport=UDP;tag=9c709222
To: sip:Alice@192.168.4.4;transport=UDP;tag=QFXyg6gcByvUH
Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
CSeq: 1 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces WWW-Authenticate: Digest realm=”192.168.4.4”, nonce=”62fb812c-71d2-4a36-93d6-e0008e6a63ee”, algorithm=MD5, qop=”auth”
Content-Length: 0
The 401 message indicates not authenticated and is FreeSWITCH’s response to Alice’s request. The meaning of each message header is basically the same as that in the request. Among them, “CSeq:1 REGISTER” means that it is a response to the REGISTER request with a CSeq of 1 just received. At the same time, it generates an authentication digest (WWW-Authenticate) on the local end and sends it to Alice.
After Alice receives the 401 with the digest, she re-initiates the registration request, this time adding the authentication information (Authorization header) generated based on the received digest and her own username and password. At the same time, you may also notice below that the CSeq sequence number has changed to 2. The following is the reissued registration request information:
recv 846 bytes from udp/[192.168.4.4]:5090 at 12:30:57.921011:
REGISTER sip:192.168.4.4;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:5090;
branch=z9hG4bK-d8754z-dae1693be9f8c10d-1—d8754z-;rport Max-Forwards: 70
Contact: sip:Alice@192.168.4.4:5090;rinstance=d42207a765c0626b;transport=UDP
To: sip:Alice@192.168.4.4;transport=UDP
From: sip:Alice@192.168.4.4;transport=UDP;tag=9c709222 Call-ID:
NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE. CSeq: 2 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
User-Agent: Zoiper rev.5415
Authorization: Digest username=”Alice”,realm=”192.168.4.4”,
nonce=”62fb812c-71d2-4a36-93d6-e0008e6a63ee”, uri=”sip:192.168.4.4;transport=UDP”,
response=”32b5ddaea8647a3becd25cb84346b1c3”,
cnonce=”b4c6ac7e57fc76b85df9440994e2ede8”, nc=00000001,qop=auth,algorithm=MD5
Allow-Events: presence
Content-Length: 0
After FreeSWITCH receives the registration message with authentication, it verifies
Alice’s identity. If the authentication passes, it responds to Alice with a 200 OK
message, indicating that the registration is successful. The returned 200 OK
message is as follows:
send 665 bytes to udp/[192.168.4.4]:5090 at 12:30:57.936940:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.4.4:5090;
branch=z9hG4bK-d8754z-dae1693be9f8c10d-1—d8754z-;rport=5090 From: <sip:Alice@192.
168.4.4;transport=UDP>;tag=9c709222
To: sip:Alice@192.168.4.4;transport=UDP;tag=rrpQj11F86jeD
Call-ID: NmFjNzA3MWY1MDI3NGViMjY1N2QwZDlmZWQ5ZGY2OGE.
CSeq: 2 REGISTER
Contact: sip:Alice@192.168.4.4:5090;rinstance=d42207a765c0626b;transport=UDP;
expires=3600 Date: Tue, 27 Apr 2010 12:30:57 GMT
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces Content-Length: 0
If the authentication fails (possibly because Alice’s password was entered
incorrectly), a 403 Forbidden or other failure message will be responded to. The content of the message is as follows:
send 542 bytes to udp/[192.168.4.4]:5090 at 13:22:49.195554:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.4.4:5090;
branch=z9hG4bK-d8754z-d447f43b66912a1b-1—d8754z-;rport=5090 From: <sip:Alice@192.
168.4.4;transport=UDP>;tag=c097e17f
To: sip:Alice@192.168.4.4;transport=UDP;tag=yeecX364pvryj
Call-ID: ZjkxMGJmMjE4Y2ZiNjU5MzM5NDZkMTE5NzMzMzM0Mjc.
CSeq: 2 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-16981M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER,
NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces Content-Length: 0
It can be seen that during the entire registration process, Alice’s password will
not be transmitted directly in the SIP message, thus ensuring the security of the
authentication process to the greatest extent.
If Alice registers successfully, FreeSWITCH will record Alice’s contact address (Contact field) in the SIP message. If someone calls Alice in the future,
FreeSWITCH can send a SIP message to the contact address to establish the call.
5. SIP call flow
First, Bob sends an INVITE message to Alice to request to establish a SIP session. Alice’s UA responds with a 100 Trying message, which means that I have received your request and will wait for a while. Then Alice’s phone started ringing, and she sent a message back to the other party, 180 Ringing, saying that my place was already ringing, and Alice might come over to answer the call soon after hearing it. After receiving the message, Bob’s UA can play a ringback tone to indicate to Bob that the other party’s phone is ringing. Then Alice answers the phone, and she sends a 200 OK message to Bob. This message is the final response to the INVITE message (all status codes greater than 1 are final responses), and the previous 100 and 180 messages are temporary status, just indicating The progress of the call. After receiving the 200, Bob replies with an ACK confirmation message to Alice. INVITE-200-ACK completes the “three-way handshake” operation to ensure that the call can proceed normally. Among them, INVITE-1xx-200 and other messages are collectively called a transaction. At this time, Bob is already talking to Alice. The content of their call (voice data) is transmitted in RTP packets outside of SIP. We will discuss RTP in detail later.
Finally, Alice hangs up the phone and sends a BYE message to Bob. Bob sends back 200 OK after receiving the BYE, and the call is completed. Among them, BYE and 200 OK are also transactions, and all the above messages are called a dialogue (Dialog, also translated as conversation).
The above describes the simplest SIP call process. Actually, SIP has some other messages. SIP messages can be roughly divided into two categories: requests and responses. The request is sent by UAC. After reaching UAS, UAS sends back a response message. Some response messages require confirmation (ACK) to complete the three-way handshake. The request messages include basic INVITE, ACK, OPTIOS, BYE, CANCEL, REGISTER, and some extensions such as re-INVITE, PRACK, SUBSCRIBE, NOTIFY, UPDATE, MESSAGE, REFER, etc. The response message contains a status code and a reason phrase (Reason Phrase). Similar to HTTP responses, status codes consist of three digits:
·The response of the 1xx group is temporary, indicating the progress of the call;
·2xx indicates that the request has been successfully received, understood and accepted;
·3xx is redirection, indicating that the SIP request needs to be forwarded to another UAS for processing;
·4xx indicates that the request failed. This failure is usually caused by the client or the network, such as incorrect password, empty number, etc. The client should modify the request and resend it;
·5xx is an internal server error, indicating that the server has an error and cannot respond to legal requests;
·6xx is a global error, such as 600 Busy Everywhere.
The status code is followed by a reason phrase (such as OK in 200 OK and Busy Everywhere just mentioned), which is a simple explanation of the previous status code.