SIP using SDP with offer/Answer Model

According to the RFC3261-13.2.1, the offer/answer model used by the SIP is established in the dialog environment. The RFC also specifically imposes restrictions on offer/answer Interaction:

1.
The initial offer must be in the invite message or the first reliable non-Failed response. Note: At that time, the reliability Effect of rfc3261 was only 2 **. Next we will talk about 1 ** (except 100.

2.
If the initial offer is in the invite message, the answer must appear in a reliable non-failure response. The answer may be included in 1 ** (but the answer must be consistent with the later 2 **). UAC will ignore the answer in the response after the same transaction.

3.
If the initial offer appears in the first reliable non-failure response, the answer must appear in the confirmation message (ACK) for the response ).

4.
If the answer of the first offer has been sent or accepted, the UAC can continue to send the new offer. On the contrary, if the answer of the previous offer is not confirmed, the new offer cannot be sent.

5.
If the answer for the initial offer has been sent or accepted, UAS prohibits the new offer from being included in the Response Message of the same transaction later.

 

 

According to the RFC3262-5, new extensions are introduced for the offer/Anwer model.

1.
If an INVITE message carries an offer, UAS must provide answer in a reliable non-failure response. This creates a session before the call is complete. Similarly, answer can appear in 1 ** because rfc3262 provides the prack method to ensure that 1 ** message is a reliable message.

2.
If the UAC receives an offer from 1 **, it must include an answer in the prack method. However, if the UAC receives the answer in 1 **, it may bring a new offer in the prack. If UAS receives an offer from prack, it must include an answer in 2.

3.
If the offer/answer interaction is successful, you can establish a session before the invite transaction is completed.

4.
If there is an offer in 1 **, UAS cannot send 2 ** before receiving confirmation for 1 **.

 

 

According to rfc3264, the offer establishes a media selection item (provided by the top layer such as the SIP), and the answer side can accept or reject the item, depending on the top layer. UA can update sessions through new offer/answer interactions. However, a new offer cannot be initiated before the old offer/answer interaction ends.

1.
Initiate an initial offer: Although SDP (rfc4566) allows multiple sessions in an SDP message, SDP messages with the offer/answer model can only contain one conversation description.

2.
Offer can contain 0 or more media streams (each media stream is described using a "m =" Row and related attributes ). The zero media streams represent only connections, and then the session can be updated through the new offer.

3.
Create a single-point propagation media offer: 1) media stream direction, including recvonly, sendrecv (default), sendonly, and inactive. However, in the RTP protocol, RTCP is not affected by this direction, that is, it is in the working state under any settings.

4.
For a media stream in the direction of recvonly and sendrecv, the port number and address in offer indicate the place where the provider accepts the media stream. For sendonly Media
For stream, the port numbers and addresses in offer indirectly indicate the places where the provider accepts RTCP (unless otherwise specified, the RTCP port is one bit higher than the RTP Port ). If the port is 0, only
Provides, rejects, or terminates a media stream.

5.
For sendonly and sendrecv streams, answer may indicate different load type numbers for the same encoding (Payload
Type number), in this case, offer must take the number value in answer.

6.
For RTP streams, you need to use "A = rtpmap" to map the RTP media load type number. If there is no corresponding "A = rtpmap" line, the current default configuration is used (RFC
1890 ).

7.
The encoding columns in the "M =" row must be prioritized.

8.
For each "m =" row in the offer, the answer must have the corresponding "m =" Row. The "t =" line in answer must be the same as the offline line.

9.
Decline an offer stream. The port value of this stream must be set to 0.

10.
If offer is sendonly, answer must be recvonly or inactive. If offer is recvonly, answer must
Is sendonly or inactive. If offer is sendrecv, answer must be sendrecv, recvonly,
Sendonly or inactive; if the offer is inactive, the answer must be inactive.

11.
Even if the offer type is senonly, the answer address and port must exist because RTCP needs to be transferred.

12.
If it is RTP, offer uses a specific load number to correspond to a specific encoding. Answer should maintain this relationship.

13.
The "M =" Row encoding in answer should be prioritized so that offer can use the highest priority option. Even so, it is recommended that answer take the same priority as offer.

14.
Ptime indicates the acceptable packaging interval, but does not require the ptime values of both parties to be consistent. However, when sending a media stream, it should be sent according to the packaging interval indicated by ptime.

15.
For RTP streams, answer uses the load encoding number provided by offer.

16.
After the offer receives the answer, it must use one of the media types in answer, and the first in the arrangement should be used.

 

According to the above,

The interaction between the offer and answer models is as follows:

Figure 1 offline/Answer Model interaction Diagram

The interaction between SIP and the offline/answer model is as follows:

Figure 2 interaction between SIP and the offer/Answer Model 1

Figure 3 interaction between SIP and the offer/Answer Model 2

Figure 4 Interaction Between SIP and the offer/Answer Model 3

Figure 5 interaction between SIP and the offer/Answer Model 4

Note: In the figure, null indicates that the offer/answer model has completed interaction, and the SDP is not empty. In this case, the media options in SDP are determined, so they will not be changed.