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.