Patent Application
20070280127
The above and other features and advantages of embodiments of the invention will become readily apparent by reference to the following detailed description when considered in conjunction with the accompanying drawings.
As will be apparent to those skilled in the art from the following disclosure, the invention as described herein may be embodied in many different forms and should not be construed as limited to the specific embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will fully convey the principles of the invention to those skilled in the art.
In RTCP, a packet format packet type (PT) field includes a number which identifies the type of packet. RTCP packet types include, for example, Sender Report (SR), Receiver Report (RR), and Source Description (SDES). Values of 200-208 are already allocated and registered with Internet Assigned Numbers Authority (IANA), the organization that oversees IP address allocation and other Internet protocol assignments. A new RTCP message type, for example, 209, may be defined to identify a sub-RTCP session. The suggested type of packet does not fall under any of the types already defined in RFC 3550 and may be registered with IANA to avoid potential conflict in the future.
The Sub-RTCP message may be formatted as shown in
Referring now to
Refer now to
When an RTCP message arrives at an interface at a VoIP node 31, for example at LEGe(i) on VNi, in block 250, the interface preferably looks into the RTCP message type to decide if the message needs to be forwarded out to its next-hop VoIP node or just digested locally on VNi. In block 260, if the RTCP message is identified as a sub-RTCP packet, for example, message type 209 for a sub-RTCP session, the sub-RTCP message will be intercepted and processed accordingly to generate the media statistics for its corresponding media segment, for example, between VNi and VNi+1. If the interface does not recognize the message type, i.e., the VoIP node is not RTCP capable, then RTCP message is discarded. Otherwise, in block 270, all other RTCP messages may be forwarded out to the destination endpoint.
Through a sub-RTCP session, all of the defined media statistics specified in RFC 3550 such as packet loss, fraction loss, inter-arrival jitter, round trip time, and other statistics defined in RFC 3611, RTP Control Protocol Extended Reports (RTCP XR), as well as RTCP XR-HR (defined in IETF draft) may be generated. Alternatively, other media statistics may be monitored and need not be limited to those typically collected using RTCP.
The sub-RTCP session does not depend on an endpoint's RTCP capability or whether an RTCP session is established. However, if the endpoints are capable of establishing RTCP sessions, a sub-RTCP session may be tunneled through an existing end-to-end RTCP session. Thus, no extra RTP/RTCP ports are required.
RTP and RTCP share a relationship. RTP may be assigned to a port x, and RTCP may be assigned to a port x+1 at the VoIP interface. To calculate delay accurately, for example, it is important that RTCP packets follow the associated RTP packets on the same path. In one embodiment, a sub-RTCP session may also be assigned to the same port x+1 as the RTCP session. Thus, when an end-to-end RTCP session is established and a sub-RTCP session is also established to monitor a media segment between Vn and Vn+1, the end-to-end RTCP packets and the sub-RTCP packets share the channel at the media segment between Vn and Vn+1. However, at any given time, only one of the end-to-end RTCP packets and the sub-RTCP packets can use port x+1. A switch preferably provides for a means for selecting which of the end-to-end RTCP or sub-RTCP has priority to use port x+1. In one embodiment, the end-to-end RTCP packets may be given priority. In another embodiment, the sub-RTCP packets may have priority instead.
Alternatively, a segment RTCP session between two peer VoIP nodes can be established for collecting the inter-VoIP node segment statistics. In this embodiment, the end-to-end RTCP messages may be relayed through the segment RTCP session to its next hop until its endpoint destination is reached. Similarly, a message type value may be used to indicate a segment RTCP message to relay the end-to-end RTCP messages. A packet type value for relaying RTCP messages may be registered with IANA.
Having described exemplary embodiments of the invention, it should be apparent that modifications and variations can be made by persons skilled in the art in light of the above teachings. Therefore, it is to be understood that changes may be made to embodiments of the invention disclosed that are nevertheless still within the scope and the spirit of the claims.
