Lines Matching refs:participant
200 participant multimedia conferences, it is not limited to that
302 participant sends audio data in small chunks of, say, 20 ms duration.
307 conference, for example, to accommodate a new participant that is
486 communicating with RTP. A participant may be involved in multiple
490 media into a single data stream. A participant distinguishes
497 participant, as in the case of individual unicast network
498 addresses and port pairs. In the unicast case, a participant may
518 participant receiving from the other two on separate port pairs.
519 If each participant sends RTCP feedback about data received from
520 one other participant only back to that participant, then the
522 sessions. If each participant provides RTCP feedback about its
523 reception of one other participant to both of the other
544 particular RTP session (see Section 8). A participant need not
547 provided through RTCP (see Section 6.5.1). If a participant
1086 each participant. Receivers may also require the CNAME to
1087 associate multiple data streams from a given participant in a set
1095 participant send its control packets to all the others, each can
1101 information, for example participant identification to be
1239 An individual RTP participant SHOULD send only one compound RTCP
1241 participant to be estimated correctly (see Section 6.2), except when
1259 at least one distinct participant. Note that each of the compound
1304 reports from each participant were sent at a constant rate, the
1355 to a resource reservation protocol, and so that each participant can
1419 participant is present. The RECOMMENDED value for a fixed minimum
1435 calculating the participant timeout interval (see Section 6.3.5)
1535 A participant MAY mark another site inactive, or delete it if not yet
1575 To execute these rules, a session participant must maintain several
1603 over all RTCP packets sent and received by this participant. The
1617 session participant should scale with the group size. This interval
1633 participant is a sender or not (based on the value of we_sent).
1634 If the participant is a sender (we_sent true), the constant C is
1652 2. If the participant has not yet sent an RTCP packet (the variable
1673 Upon joining the session, the participant initializes tp to 0, tc to
1691 The participant adds its own SSRC to the member table.
1695 When an RTP or RTCP packet is received from a participant whose SSRC
1697 value for members is updated once the participant has been validated
1701 When an RTP packet is received from a participant whose SSRC is not
1758 At occasional intervals, the participant MUST check to see if any of
1759 the other participants time out. To do this, the participant
1773 The participant MUST perform this check at least once per RTCP
1778 When the packet transmission timer expires, the participant performs
1810 When a participant wishes to leave a session, a BYE packet is
1813 system, a participant MUST execute the following algorithm if the
1814 number of members is more than 50 when the participant chooses to
1818 o When the participant decides to leave the system, tp is reset to
1825 o Every time a BYE packet from another participant is received,
1826 members is incremented by 1 regardless of whether that participant
1842 A participant that does not want to wait for the above mechanism to
1844 sending a BYE at all. That participant will eventually be timed out
1856 participant decides to leave, the participant MAY send a BYE packet
1857 immediately. Alternatively, the participant MAY choose to execute
1860 In either case, a participant which never sent an RTP or RTCP packet
1865 The variable we_sent contains true if the participant has sent an RTP
1868 participants listed in the senders table. If the participant sends
1875 the participant -- if an RTP packet has not been transmitted since
1876 time tc - 2T, the participant removes itself from the sender table,
1889 bandwidth allocated to a single participant be used to carry the
1918 binding through a common CNAME for each participant, for example in a
2587 participant in a set of related RTP sessions, the CNAME SHOULD be
2588 fixed for that participant.
2623 one in the participant's electronic mail address.
2641 across multiple media tools belonging to one participant in a set of
2669 desirable for display in participant lists, and therefore might be
3390 established source. It resolves collisions with the participant's
3393 loop of the participant's own packets, the algorithm will choose a
3439 In order to track loops of the participant's own data packets, the
3451 For the algorithm as shown, it is assumed that the participant's own
3454 comparison against the participant's own source identifier.
3481 if (source identifier is not the participant's own) {
3494 /* A collision or loop of the participant's own packets */
3502 participant's own) {
3794 same port pair. A participant MUST NOT assume that the source port
3797 being sent in both directions, each participant's RTCP SR packets
3798 MUST be sent to the port that the other participant has specified for
4060 participant. In addition, RTP may be sent via IP multicast, which
4884 the next scheduled event for that participant, either an RTCP report
4910 o NewMember(p) returns a 1 if the participant who sent packet p is
4916 o NewSender(p) returns a 1 if the participant who sent packet p is
5284 the incidence and duration of false participant timeouts when the
5348 o Timing out a participant is to be based on inactivity for a number