SIP (7)

 

1.1.1. Dialog

It is defined for two UA. After UA sends the initial invete request, it is possible to create a dialog only when it receives a non-Failed response. UA mainly uses three parameters to identify whether a call belongs to the same dialog: Call-ID, tag parameter in the from field, and tag parameter in the to field.

For an UA, the initial invete request sent contains the from domain and its tag parameter and call-ID parameter, while the tag parameter in the to domain is added by the called side.

According to the definition of dialog, a dialog is created only when the to field in a 200 or message contains the tag parameter.

For a kialog created through a message (H is generally a 18 * message) in, we call it an early session (eary DIALOG) because only one-way channel is established between the master and the call, no session is established.

The most common is the dialog created through the 200 message. At this time, the master and the called sides have established a session.

Generally, sessions and dialog correspond one to one. For example, for a two-party call, because the combination of tag + to domain tag + call-ID in the from domain is unique, the dialog can represent the session. However, there are also special cases: for example, the convener of a meeting can receive more than 200 messages, and the tag parameters in the to field of each 200 message are different, therefore, for the party that calls the meeting, multiple dialog are established at this time, and the relationship between the session and dialog is one-to-many. In this case, we cannot replace the session with the dialog.

1.2. Timer

A table of timer values

Timer	Value	Meaning
T1	500 ms	RTT estimate
T2	4S	The maximum retransmit interval for non-invite requests and invite responses
T4	5S	Maximum duration a message will remain in the Network
Timer	Initially T1	Invite request retransmit interval, for UDP only
Timer B	64 * T1	Invite transaction timeout Timer
Timer C	> 3 min	Proxy invite transaction timeout
Timer d	> 32 s for UDP 0 s for TCP/sctp	Wait time for response retransmits
Timer E	Initially T1	Non-invite request retransmit interval, UDP only
Timer F	64 * T1	Non-invite transaction timeout Timer
Timer g	Initially T1	Invite response retransmit Interval
Timer H	64 * T1	Wait time for ACK receept
Timer I	T4 for UDP	Wait time for ACK retransmits
Timer J	64 * T1 for ud	Wait time for non-invite request retransmits
Timer K	T4 for UDP 0 s for TCP/sctp	Wait time for response retransmits

 

Client invite Timer

After the SIP entity (including UA and proxy) sends an INVITE message, whether it is reliable transmission or unreliable transmission, the entity starts transaction protection and starts the timer B (time B = 64t1, if T1 = 500 ms, the timer is 32 S ).

In the case of unreliable transmission, the entity starts the T1 timer (500 ms) at the same time. If no response is received at the end of T1, the entity resends the invite message, the subsequent intervals are 2t1, 4t1, 8t1, 16t1, and 32t1. During this period, if a response message is received, the entity will terminate the resend.

When the timer B (timer B = 64t1) ends, if the entity still does not receive a response message, the entity will terminate the call request.

Server invite Timer

When the called user responds, The called UA (UAs) sends a 200 message to the Peer to confirm the invite message) after receiving the 200 message, an ACK message is sent, indicating that the 200 message is received.

Therefore, for the sever side, after sending a 200 message, the timer H (timer H = 64t1) will be started to wait for the ACK message ).

In the case of unreliable transmission, the server starts T1 and does not receive the ACK message, and UAS resends the 200 message. The subsequent intervals are 2t1, 4t1, and 8t1 respectively. When the interval reaches T2 (t2 = 8t1), the subsequent retransmission interval will always be T2.

When the timer H (timer H = 64t1) ends, if the entity still does not receive the ACK confirmation message, the entity will terminate the call request.

Other final response messages, such as 200-message retransmission and timer protection, are the same as those of messages.

Client non-invite Timer

For other request (non-invite request) messages, such as INFO messages or bye messages, the entity does not need to confirm the final response message after receiving the final response message, therefore, the re-sending behavior of messages is different from that of INVITE messages.

After the entity sends the info or bye message, the entity starts the timer F (timer F = 64t1). If the timer F ends and does not receive the final response message, the entity will clear the transaction.

In the case of unreliable transmission, the object starts the T1 timer at the same time. If no response message is received, the re-sending of the object will be the same as described in section 3.6.2. If a temporary response message is received during this period, the entity resends at T2 intervals.

 

 

2. SAP

2.1. Overview

The SAP-Session announcement protocol is used to send relevant session establishment information to the expected participants to notify a multicast multimedia meeting or other multicast sessions. The SAP protocol itself does not establish a session. It only notifies other participants in a multicast group of the information necessary to establish a session, such as the video or audio encoding method adopted, after receiving the notification packet, the participant can start the corresponding tool and set the correct parameters to establish a session with the initiator of the meeting (the established session can use the SIP protocol ).

The initiator of the notification does not know whether each participant has received the session notification. That is to say, each participant does not reply "I have received the notification" to the initiator. Therefore, the notification initiator can only send the session notification periodically so that the participant can receive the notification as much as possible.

SAP does not send one-to-one notification packets to each participant. It sends one notification packet to a known multicast address and port through the multicast mechanism (Multicast, if the multicast group members work properly, they will receive the notification packet. Therefore, to enable all participants of the meeting to receive notifications, ensure that they participate in the multicast group.

In addition to notifying that a session is about to be initiated, a notification datagram can also notify that the session has been canceled or that some communication parameters of the session have been modified. Of course, this requires a mechanism to make these notifications target the same session.

So how does sap describe session information? This requires the use of SDP protocol. In the payload field of the SAP data packet, SDP data is usually filled, which describes the basic information necessary to establish a session. If a receiver receives a meeting announcement group, it can simply decode the SDP message and display the user's meeting information so that the receiver can understand the current meeting Status. The recipient selects the Meeting to be added and sends a request to the transfer address (multicast address plus port pair) of the Meeting. The recurrence interval of the same meeting description message is determined by the number of meetings being announced to ensure that it does not occupy too much bandwidth.

If the recipient has listened on the set time and fails to receive the announcement, the recipient can determine that the meeting has been canceled and does not exist. The term is set based on the receiver's estimation of the frequency of sending to the sender, and (arbitrarily) it is set to about 10 times the estimated sending cycle.

 

2.2. Format

 

• V-version number field is three bits and must be set to 1 (sapv2 ).
• A-address type-it can have a value of 0 or 1:

  0 the originating source field contains a 32-bit IPv4 address.

  1 The originating source contains a 128-bit IPv6 address.

• R-reserved. SAP announcers set this to 0. SAP listeners ignore the contents of this field.
• T-message type. It can have a value of 0 or 1:

  0 Session announcement Packet

  1 session deletion packet.

• E-encryption bit the encryption bit may be 0 or 1.

  1 The payload of the SAP packet is encrypted and the timeout field must be added to the packet header.

  0 the packet is not encrypted and the timeout must not be present.

• C-compressed bit. If the compressed bit is set to 1, the payload is compressed.
• Authentication length-an 8 bits unsigned quantity giving the number of 32 bit words, following the main sap header, that contain authentication data. 0 no authentication header is present.
• Message identifier hash-used in combination with the originating source, provides a globally unique identifier indicating the precise version of this announcement.
• Originating source-this field contains the IP address of the original source of the message. this is an IPv4 address if the field is set to zero; otherwise, it is an IPv6 address. the address is stored in network byte order.
• Timeout-when the session payload is encrypted, the detailed timing fields in the payload are not available to listeners not trusted with the decryption key. under such circumstances, the header provided des an additional 32-bit timestamp field stating when
  The session shoshould be timed out. The value is an unsigned quantity giving the NTP time in seconds at which time the session is timed out. It is in network byte order.
• Payload type-the payload type field is a mime content type specifier, describing the format of the payload. this is a variable length ASCII text string, followed by a single zero byte (ascii nul ). default Application/SDP.
• Payload-the payload field provided des various sub fields.

 

2.3. Process

2.3.1. Join the meeting

Joining a light-weight multimedia session

User A |

Creates | SDP/SAP |

Conference | -----------> |

| User B

| SDP/sap igmp | starts

| -----------> IGMP/-- <--------- | session

| IGMP/-<------/| directory

| ----------- <---------/|

|

| SDP/SAP |

| --------------------------------------------> |

|

User A |

Starts | RTP |

Sending | ===========> |

| RTCP |

| -----------> |

|

| RTP |

| ===========> |

|

| RTP | user B

| ============> IGMP | joins

| IGMP/-- <--------- | Conference

| IGMP/-<------/|

| ----------- <---------/| User's app

| RTCP | sends RTCP

| RTP/-- <--------- | session

| ===================================================== ====>| Message

| <-----------------------------/|

| RSVP path message |

| --------------------------------------------> |

| User's app

| RTP/----------- | makes

| ===================================================== ====>| Reservation

| RSVP resv message/-----/|

| <-----------------------/|

|

| RTP | quality

| ================================================ ====>| Of service

| Improves

 

Above shows an example time sequence involved in setting up a light-weight session between two sites. in this case, Site A creates a session advertisement, and some time later starts sending a media stream even though there
May be no longer er at that time. some time later, site B joins the session (the multicast routing protocol here is PIM), and starts to receive the traffic. at the earliest opportunity Site B also makes an RSVP reservation to ensure the flow quality is satisfactory.
This example shoshould be taken as your strative only -- there are different ways to join sessions, and different ways to get improved quality of service.