Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The client MUST verify that the RTP packet is compliant with the syntax as specified in section 2.2.3.2. If the value of the Server-features variable in the abstract data model indicates that the server supports the com.microsoft.wm.srvppair (section 2.2.6.10.6), the client SHOULD validate that the SSRC field in the RTP packet is identical to the value of the SSRC-id variable. If the SSRC field in the RTP packet is not identical to the value of the SSRD-id variable, the client MUST ignore the RTP packet.
If this is the first RTP packet received, the client SHOULD start measuring the time until the second RTP packet is received.
After receiving the first RTP packet, the client MUST wait for the second RTP packet to be received, and then process the rules as previously specified in this section.
If this is the second RTP packet received, the client can use the time elapsed between receiving the first RTP packet and the second RTP packet to compute the bit rate at which the second RTP packet was transferred. The client SHOULD make this information available to a higher layer.
The client can determine if an RTP packet that contains packet-pair data is the last or the second-to-last such RTP packet by examining the size of the Payload field. For details, see section 2.2.3.2.
If this is the second-to-last RTP packet containing packet-pair data, the client MUST wait for the last RTP packet containing packet-pair data to be received, and then apply the rules as previously specified in this section.
After the last RTP packet containing packet-pair data has been received, the client MUST stop the Firewall timer if it is running. The client MUST then wait until a higher-layer triggered event occurs. The next higher-layer triggered event is a request to start streaming content, as specified in section 3.1.4.3.