"Go" SIP preliminary

1 , what is SIP

SIP (Session Initiation Protocol) belongs to the IP Application layer protocol, which is used to provide the user with session application on the IP network. A session refers to the communication of voice, video, and other media forms between two or more users, possibly IP telephony, conferencing, instant messaging, and so on.

SIP is a signaling protocol that corresponds to a call signaling protocol (such as SS7 ISUP) in a traditional telephony network. Building a complete multimedia communication architecture also requires a combination of other protocols, such as RTP, for media transmission, RSVP, for QoS assurance, and so on.

2 , basic functions

Initiation and management of 2.1 sessions

SIP is primarily used to create, modify, and terminate a session.

A simple example of creating a session is as follows:

• The initiating direction destination sends a SIP request message (INVITE) that contains a description of the proposed session parameters and requests that a session be established between the two;
• The destination party returns a SIP response message with a description of the accepted session parameters, accepting the session establishment request
• The initiator sends a SIP request message (ACK) to confirm the establishment of the session.

A simple example of a modified session is as follows:

• Either party in the session can send a SIP request message (Reinvite) that contains the proposed new session parameters and requests a modification of the session between the two;
• The other party returns a SIP response message (a total of OK) that contains the new session parameters that are accepted and accepts the session modification request

A simple example of ending a session is as follows:

• Either party in the session can send a SIP request message (BYE), requesting the end of the session;
• The other party returns a SIP response message (with a $ OK) to accept the session end request

2.2 User Location Management

SIP supports the mobility of users (terminals).

SIP requires the terminal to periodically send a registration request (Reggister) to the network, reporting its current location. In this way, the current address of the user (terminal) is always stored in the SIP server. When the user is called, the SIP server is able to send the SIP request to the user's current address.

3 , Physical & Network

Sip UA, the user agent, is the most basic SIP entity, which is usually the user terminal. Ideally, session creation between users can be done through SIP UA. (see section 2nd, Session Initiation and management in SIP basic functionality).

However, in order to support SIP mobility, and other advanced features such as operator call control, the signaling process for session initiation and management cannot be done directly between two SIP UA, but requires a SIP signaling network consisting of several SIP servers.

These SIP servers can be divided into two categories: the registration server and the routing server.

The primary function of the SIP Registration Server (Registrar) is to accept SIP UA registration requests and maintain user name-address mappings.

The primary function of the routing server is to route SIP messages to the target SIP UA. The routing server has two types of SIP redirection server (redirect server) and SIP Proxy Server (proxy). The former routes SIP request messages in a redirect manner, which routes SIP request messages in a proxy manner.

In redirection mode (as shown), the SIP redirect server receives a SIP request message that is returned to the initiator SIP UA via a SIP response message (302 Moved temporarily) after querying the current address of the target SIP UA. After the SIP message interaction is not related to the redirect server, the initiator SIP UA sends the request message directly to the current address of the target SIP UA.

In the proxy mode (as shown), the SIP Proxy server receives the SIP request message and, after querying the current address of the target SIP UA, forwards the SIP request message to the current address of the target SIP UA. Subsequent SIP message interactions are passed through the SIP proxy server. This allows the SIP proxy server to control the session, such as ending the session, and so on.

4 , SIP operation and SIP message

The functions provided by SIP are composed of some atomic basic functions (such as registration (registration), initiation Session (initiation), session end, etc.). Each atomic basic function is accomplished through a SIP operation.

SIP operations are based on HTTP-like request/response transaction models, and the invocation process for each operation manifests itself as a so-called transaction-containing a SIP request and one or more corresponding SIP responses. The method in the SIP request message indicates the operation being invoked.

The following table is the method that is defined in RFC 3261 and its corresponding SIP operations.

valign= width= "Top", "+", "" "" + BYE

Method Method	SIP Operations
INVITE	Session invite
ACK	Confirm Session Invitation
cancel	Cancel session invitation
End Session
Register	Register
OPTIONS	Query server capacity

SIP is a text-based (text-based) protocol that uses the UTF-8 character set. SIP messages are very similar to http/1.1, and can also contain the body of messages (message body), which is usually a conversation description (session descriptions) or something else.

There are two types of SIP messages: The request message from the client to the server (requests), the response message from the server to the client (response).

In addition to the first line, which is the request line (Request-line) and the status line (Status-line), the composition of the SIP request message and the remainder of the SIP response message is basically similar, including the Message header field (messages header) and the body (message Body) two parts (as shown).

4.1 SIP Request Message

According to the method in the request line, there are many kinds of SIP request messages, which can be used to accomplish various functions, and the following is a brief introduction.

• Invite/reinvite:invite initiates a session invitation. Reinvite (invite called reinvite), which is sent in an existing conversation, modifies the parameters of the established session.
• ACK: Complete the 3-time handshake [Invite-200-ack] established for the session, only for INVITE
• BYE: End session.
• Cancel: Cancel the session in progress (invite has been sent but has not received a final response (final response)).
• Update: Updates session parameters. It is recommended to replace Re-invite, unlike Re-invite: it can be sent when the initial INVITE is incomplete, and can be used to update session parameters in early dialogs (early dialog).

above the 4 Requests for session setup and management.

• Register: Register UA's current contact address
• OPTIONS: The ability to query the server or to the end UA, including supported methods (method), extensions (extensions), codec (codecs), etc.
• Prack: Interim response (provisional Response) confirmation. Used to confirm receipt of a temporary response, such as "183 Session Progress", to support the reliable delivery of a temporary response. It cannot be applied to "Trying" and only 101~199 temporary response is required for reliable transmission. If the prack is not received, the response message is re-transmitted.

• NOTIFY: Event notifications, specific events include, changes in business status (MWI, ... ), changes in user status, and so on.
• SUBSCRIBE: Subscription/cancellation (expires=0) event notification.
• PUBLISH: Publish event status. PUBLISH is similar to REGISTER in that it allows the user to create, modify, and remove their own state in another entity (state management entity/registrar). The addressing of the PUBLISH request is the same as for the subscribe request, and the Request-uri of the PUBLISH request is populated with the resource address of the user who wants to publish its event state.

above the 3 Requests form a SIP event publish-subscribe-notification mechanism

• Info: For transmitting Mid-call signaling information, only one info transaction exists at a time. Typically used to carry PSTN signaling messages (as MIME attachments), for example, ISDN UUI (user-to-user information).
• Message: An extension for instant messaging (IM) for delivering instant messages. The message request carries content through a MIME attachment. The message request does not initiate a SIP conversation itself, and in normal usage, each instant message is separate, very similar to the pager message. A MESSAGE request can be sent in the context of a conversation initiated by another SIP request.
• REFER: Indicates that the recipient (as identified by Request-uri) should use the information provided in the request to contact a third party. Typical application: Call Transfer features. Allowed outside an established dialogue.

4.2 SIP Response Message

Status code	Describe	Example
1xx	Informational Request received, in process	Ringing 181 Call is Being forwarded
2xx	Success Operation completed successfully	OK
3xx	Redirection Request is redirected	Multiple Choices 302 Moved temporarily
4xx	Client Error The request contains the wrong grammar, or it cannot be completed on this server	401 Unauthorized 408 Request Timeout
5xx	Server Error The request is valid, but the server cannot complete	503 Service Unavailable 505 Version Not supported
6xx	Global Failure The request cannot be completed on any server	Busy Everywhere 603 decline

4.3 SIP Message header fields

According to the method in the request line, there are many kinds of SIP request messages, which can be used to accomplish various functions, and the following is a brief introduction.

• Call-id: Used to uniquely identify a specific session or registration message. should be random to ensure that the world is unique.
  Example: Call-id:[email protected]
• From: The source-side SIP URL, which identifies the request sender, and the UAC local label.
  Example: from:sip:+1-314-342-7360 @gateway. wcom.com; tag=1234567
• To: Target SIP URL, identity request recipient, UAS local label.
  Example: To:sip:[email protected]; tag=314
• Via: Used to record the path through which the request was routed
  Example: Via:sip/2.0/tcp uunet.com
• Max-forwards: Maximum number of messages forwarded. This domain value is reduced by 1 when the service forwards the message each time, and when it becomes 0 o'clock, the server sends a 483 response (Too many Hops response).
  Example: Max-forwards:10
• CSEQ: A request sequence number that distinguishes between different requests in the same session.
  Example: Cseq:1 INVITE
  cseq:4325 BYE
  Cseq:1 REGISTER

The above 6 header fields are the required header fields in all SIP messages.

• Contact another SIP URL for direct message routing.
  Example: Contact:w Riker, acting Captain [email protected]
  Record-route needs to be on the path of subsequent messages, proxy inserts its own address in the request message
  Example: Record Route:sip.mci.com
• Route determines the routing of messages
  Example: Route:orinoco.brooks.net
• Content-length: Number of Octet in the message body
  Example: content-length:285
• Content-type: Message body Content Type
  Example: CONTENT-TYPE:APPLICATION/SDP

5 , detailed examples (excerpt from IETF RFC 3261)

Practical examples can help you get to know and understand the previous content. Here are two examples of the two most basic features of SIP: registration and session creation. In each example, the message interaction process and the necessary message content details are given.

For the sake of brevity, the content of the message given here ignores the message body and the corresponding header field ( Content-length and content-type). In addition, there are some header fields such as allow and supported that usually appear, but are not given here.

5.1 Registration

Bob registers at boot time. The message flow is as shown. Note that in order to streamline the process, there is no authentication process that is usually required at the time of registration.

Message Details:

F1 REGISTER Bob--Registrar

REGISTER sip:registrar.biloxi.com sip/2.0

VIA:SIP/2.0/UDP BOBSPC.BILOXI.COM:5060;BRANCH=Z9HG4BKNASHDS7

Max-forwards:70

To:bob <sip:[email protected]>

From:bob <sip:[email protected]>;tag=456248

Call-id: [Email protected]

cseq:1826 REGISTER

Contact: <sip:[email protected]>

expires:7200

content-length:0

This registration is valid for 2 hours (7,200 seconds)

The registration server returns a $ OK response.

F2-OK Registrar Bob

sip/2.0 OK

VIA:SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hg4bknashds7;received=192.0.2.4

To:bob <sip:[email PROTECTED]>;TAG=2493K59KD

From:bob <sip:[email protected]>;tag=456248

Call-id: [Email protected]

cseq:1826 REGISTER

Contact: <sip:[email protected]>

expires:7200

content-length:0

5.2 session establishment and demolition

Session creation is the most basic feature of SIP.

The message flow is as shown.

Message content: (Note that this does not give the details of the session Media parameter SDP)

F1 INVITE Alice--atlanta.com Proxy

INVITE Sip:[email protected] sip/2.0

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

Max-forwards:70

To:bob <sip:[email protected]>

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:142

(Alice's SDP is not shown)

F2 Trying atlanta.com Proxy--Alice

sip/2.0 Trying

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email protected]>

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

content-length:0

F3 INVITE atlanta.com Proxy--biloxi.com Proxy

INVITE Sip:[email protected] sip/2.0

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

max-forwards:69

To:bob <sip:[email protected]>

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:142

(Alice's SDP is not shown)

F4 Trying biloxi.com Proxy--atlanta.com Proxy

sip/2.0 Trying

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

; received=192.0.2.2

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email protected]>

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

content-length:0

F5 INVITE biloxi.com Proxy Bob

INVITE Sip:[email protected] sip/2.0

VIA:SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

; received=192.0.2.2

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

max-forwards:68

To:bob <sip:[email protected]>

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:142

(Alice's SDP is not shown)

F6 ringing Bob--biloxi.com Proxy

sip/2.0 ringing

VIA:SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1

; received=192.0.2.3

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

; received=192.0.2.2

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

Contact: <sip:[email protected]>

cseq:314159 INVITE

content-length:0

F7 ringing biloxi.com Proxy--atlanta.com Proxy

sip/2.0 ringing

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

; received=192.0.2.2

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

Contact: <sip:[email protected]>

cseq:314159 INVITE

content-length:0

F8 ringing atlanta.com Proxy--Alice

sip/2.0 ringing

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

Contact: <sip:[email protected]>

cseq:314159 INVITE

content-length:0

F9 OK Bob--biloxi.com Proxy

sip/2.0 OK

VIA:SIP/2.0/UDP server10.biloxi.com;branch=z9hg4bk4b43c2ff8.1

; received=192.0.2.3

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

; received=192.0.2.2

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:131

(Bob's SDP is not shown)

F10 OK biloxi.com Proxy--atlanta.com Proxy

sip/2.0 OK

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hg4bk77ef4c2312983.1

; received=192.0.2.2

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:131

(Bob's SDP is not shown)

F11 OK atlanta.com Proxy--Alice

sip/2.0 OK

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS8

; received=192.0.2.1

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:131

(Bob's SDP is not shown)

F12 ACK Alice--Bob

ACK Sip:[email protected] sip/2.0

VIA:SIP/2.0/UDP PC33.ATLANTA.COM;BRANCH=Z9HG4BKNASHDS9

Max-forwards:70

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:314159 ACK

content-length:0

Now the media session between Alice and Bob is established.

Bob hangs the machine first. Note that Bob's SIP phone maintains its own cseq numbering space, which is here starting from 231. Because it is the request that Bob sends, the URIs and tags parameters of the to and from header fields are swap.

F13 BYE Bob, Alice

BYE Sip:[email protected] sip/2.0

VIA:SIP/2.0/UDP 192.0.2.4;BRANCH=Z9HG4BKNASHDS10

Max-forwards:70

From:bob <sip:[email PROTECTED]>;TAG=A6C85CF

To:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:231 BYE

content-length:0

F14-OK Alice-Bob

sip/2.0 OK

VIA:SIP/2.0/UDP 192.0.2.4;BRANCH=Z9HG4BKNASHDS10

From:bob <sip:[email PROTECTED]>;TAG=A6C85CF

To:alice <sip:[email protected]>;tag=1928301774

call-id:a84b4c76e66710

cseq:231 BYE

content-length:0

"Go" SIP preliminary