SIP(七)

 

1.1.1.    Dialog

是針對兩個UA定義的，當UA發送初始INVETE請求後，只有接收到非失敗響應才有可能建立DIALOG.UA主要3個參數來識別呼叫是否屬於同一個DIALOG:call-id、FROM域中的TAG參數、TO域中的TAG參數。

對一個UA而言，發送的初始INVETE請求中帶有FROM域及其TAG參數和CALL-ID參數，而TO域中的TAG參數則由被叫側添加。

根據DIALOG的定義，只有當101-199或200訊息中的TO域中帶有TAG參數時，此時才建立DIALOG.

對通過101-199訊息（h目前一般是18*訊息）建立的KIALOG,我們稱為早期會話（EARY DIALOG）,因為此時主被叫間只建立了單向通道，並沒有建立會話。

最為常見的是通過200訊息建立的DIALOG,此時主被叫雙方已經建立會話。

一般情況下，會話和DIALOG是一一對應的關係。例如一個兩方參與的呼叫，由於此時FROM域中TAG+TO域中TAG+CALL-ID的組合是惟一的，所以此時可以以DIALOG來代表會話。但也有特殊情況：比方會議呼叫，召集會議的一方可以接收到多個200訊息，而每個200訊息中TO域中的TAG參數都不相同，因此對召集會議的一方而言，此時建立了多個DIALOG,且會話與DIALOG是一對多的關係，在這種情況下，我們就不能夠用DIALOG來代替會話。

1.2.      Timer

A Table of Timer Values

Timer	Value	Meaning
T1	500ms	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 A	initially T1	INVITE request retransmit interval, for UDP only
Timer B	64*T1	INVITE transaction timeout timer
Timer C	> 3min	proxy INVITE transaction timeout
Timer D	> 32s for UDP 0s 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 receipt
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 0s for TCP/SCTP	Wait time for response retransmits

 

用戶端invite timer

當SIP實體（包括ua和PROXY）發送INVITE訊息後，無論是可靠傳送還是不可靠傳送，實體都會啟動TRANSACTION保護，啟動定時器B（TIME B=64T1,如果T1=500MS,則此時定時器為32S）.

在不可靠傳送的情況下，實體同時會啟動T1定時器（500MS）,如果T1終了沒有收到任何響應，實體將會重發INVITE訊息，以後的間隔分別為2T1、4T1、8T1、16T1、32T1,在此期間，如果收到響應訊息，實體將會終止重發行為。

當定時器B(TIMER B=64T1)終了時，如果實體仍然沒有收到響應訊息，實體將會終止該呼叫請求。

伺服器端invite timer

當被叫使用者應答時，被叫側UA(UAS)將會向對端發送200訊息，表示對INVITE訊息的確認，按照我們前面介紹的，主叫側UA(UAC)收到200訊息後，將會發送ACK訊息，表示收到200訊息。

因此對SEVER側來講，當發送200訊息後，為了等待ACK訊息，將會啟動定時器H(TIMER H=64T1).

在不可靠傳送的情況下，SERVER還會啟動T1終了時，沒有收到ACK訊息，UAS將會重發200訊息。以後的間隔分別為2T1、4T1、8T1，當間隔達到T2(T2=8T1)後，後續重發的間隔將一直為T2.

當定時器H(TIMER H=64T1)終了時，如果實體仍然沒有收到ACK確認訊息，實體將會結束通話請求。

其他最終響應訊息，例如300-699訊息的重傳和定時器保護也與200訊息的相同。

用戶端非invite timer

其他請求（非INVITE請求）訊息，例如INFO訊息或BYE訊息，實體接收到最終響應訊息後，由於不需要對最終響應訊息進行確認，因此訊息重發行為上與INVITE訊息的重發存在不同。

當實體發送INFO或BYE訊息後，實體將會啟動定時器F(TIMER F=64T1).如果定時器F終了時，沒有收到最終響應訊息，實體將會清掉TRANSACTION.

在不可靠傳送的情況下，實體同時啟動T1定時器，如果沒有收到任何響應訊息，實體重發的行為將與3.6.2節中所述的相同。如果在此期間收到臨時響應訊息，實體將會以T2的間隔重發。

 

 

2.    SAP

2.1.      概況

       SAP-Session Announcement Protocol會話通告協議，其目的是為了通知一個多播的多媒體會議或其他多播會話而將相關的會話建立資訊發送給所期望的會議參與者。SAP協議本身並不建立會話，它只是將建立會話所必要的資訊，例如所採取的視頻或音頻編碼方式通知給其他在一個多播組內的參與者，當參與者接收到該通知數據包後就可以啟動相應的工具並設定正確的參數向該會議的發起者建立會話了（建立會話可以使用SIP協議）。

　　通知的發起者並不知道各參與者是否收到了會話通知，也就是說每個參與者並不向通知發起者回複“我收到了通知”的確認；因此，通知發起者只能夠通過周期性地發送這個會話通知從而最大可能地使參與者收到通知。

　　SAP並不是向每個參與者一一發通知數據包，它是通過多播的機制（multicast）向一個已知的多播地址和連接埠一次性發送一個通知數據包，該多播組內的成員如果工作正常的化就會收到該通知數據包。因此，為了使會議的參與者都能夠接收到通知，就要確保其參加到該多播組內。

　　一個通知數據報除了可以通知某會話將要發起外，還可以通知該會話取消了或該會話的某些通訊參數已被修改了。當然，這需要相應機制使這幾個通知都是針對同一會話的。

　　那麼SAP如何描述會話的相關資訊，這就需要藉助SDP協議了。在SAP資料包的payload欄位中一般情況下填充的就是SDP資料，它描述了建立會話所必要的基本資料。如果某個接收方收到一個會議宣布分組，則可簡單地解碼該SDP訊息，然後顯示該使用者的會議資訊，以便接收方瞭解目前的會議狀況。接收方選擇想要加入的會議，並向該會議的傳輸地址（組播地址加上連接埠對）發出請求加入的申請。同樣的會議描述訊息的重複時間間隔由正在被宣布的會議的數量決定，以確保其不會佔用太多的頻寬。

如果接收方已經監聽了設定的時間並且沒有能夠收到會議宣布，那麼接收方可以斷定該會議已經取消並且不再存在。該期限的設定依據為接收方對寄件者應該發送的頻度的估計量，並且（任意地）將它設定為這個估計的發送周期的10倍左右的時間。

 

2.2.      格式

 

 

• 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 8bits 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 A 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 includes an additional 32-bit timestamp field stating when
  the session should 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 includes various sub fields.

 

2.3.      過程

2.3.1.    會議加入

               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 receiver 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 should be taken as illustrative only -- there are different ways to join sessions, and different ways to get improved quality of service.