Abstract: A system and method for transferring Media over IP (MoIP) packets over an overlay network is provided. The system provides specially designed overlay network units located at key points in the IP network effectively creating an overlay network that is capable of interacting both on the overlay level as well as over the standard IP network.

Abstract: Techniques are described for aggregating multiple media packets to improve end-to-end bandwidth efficiency. The techniques include using an RTP aggregation protocol that is not sensitive to packet loss to aggregate multiple media packets under a single header. According to the RTP aggregation protocol, the single header for an aggregated media packet comprises a version field, a zero field, a sequence number field and a trunk ID field. The single header encapsulates the aggregated payload, which is an aggregation of Real-Time Protocol (RTP) segments. An RTP segment either has a compressed format or an uncompressed format. The uncompressed RTP segment includes the complete uncompressed RTP packet copied from the original User Datagram Protocol (UDP) packet. The compressed RTP segment includes the payload of the original RTP rather than the complete original RTP packet.

Abstract: A method and apparatus for communicating a COPS protocol policy to a non-COPS-enabled network device is provided. A COPS proxy is connected between a policy server and a non-COPS-enabled network device. The policy server is configured to communicate COPS protocol policies to the COPS proxy, which is, in turn, configured to translate the COPS protocol policy into a policy that is in accordance with a policy protocol that the non-COPS-enabled network device can receive and correctly interpret (“non-COPS protocol”). The translation of the policy utilizes a mapping database that delineates predetermined relationships between COPS protocol policies and the non-COPS protocol policies. More specifically, the mapping database can include relationships between COPS protocol policy information base variables, network device roles and characteristics, and non-COPS protocol parameters and associated values. Further, the COPS proxy can be configured to detect and reconcile policy conflicts for one or more network devices.

Abstract: Techniques are described for aggregating multiple media packets to improve end-to-end bandwidth efficiency. The techniques include using an RTP aggregation protocol that is not sensitive to packet loss to aggregate multiple media packets under a single header. According to the RTP aggregation protocol, the single header for an aggregated media packet comprises a version field, a zero field, a sequence number field and a trunk ID field. The single header encapsulates the aggregated payload, which is an aggregation of Real-Time Protocol (RTP) segments. An RTP segment either has a compressed format or an uncompressed format. The uncompressed RTP segment includes the complete uncompressed RTP packet copied from the original User Datagram Protocol (UDP) packet. The compressed RTP segment includes the payload of the original RTP rather than the complete original RTP packet.

Abstract: A system and method for transferring Media over IP (MoIP) packets over an overlay network is provided. The system provides specially designed overlay network units located at key points in the IP network effectively creating an overlay network that is capable of interacting both on the overlay level as well as over the standard IP network.

Abstract: Techniques are described for aggregating multiple media packets to improve end-to-end bandwidth efficiency. The techniques include using an RTP aggregation protocol that is not sensitive to packet loss to aggregate multiple media packets under a single header. According to the RTP aggregation protocol, the single header for an aggregated media packet comprises a version field, a zero field, a sequence number field and a trunk ID field. The single header encapsulates the aggregated payload, which is an aggregation of Real-Time Protocol (RTP) segments. An RTP segment either has a compressed format or an uncompressed format. The uncompressed RTP segment includes the complete uncompressed RTP packet copied from the original User Datagram Protocol (UDP) packet. The compressed RTP segment includes the payload of the original RTP rather than the complete original RTP packet.

Abstract: A method and apparatus are provided for automatic reverse-direction or bi-directional quality of service treatment of network data flows. A network device located at the edge or border of a network, such as a router that is connected to another network, identifies a data flow originating within its network and directed outside the network, and having packets set with quality of service treatment values. Identified quality of service treatments may be IP precedence, DSCP marking of packets in the flow, an RSVP PATH message, etc. The network device creates and stores, in its local memory, values that uniquely identify the flow and that tell the device how to treat packets of the same flow that are transmitted in the opposite or inbound direction. Upon identifying a corresponding inbound flow with quality of service treatment, all packets of the flow are given a pre-configured quality of service treatment based upon the quality of service treatment of the originally identified flow.

Abstract: A method and apparatus for providing network resource reservation capability for receiver nodes that either cannot or do not facilitate RSVP processes is provided. A RESV proxy is connected between an anticipated sender node and an anticipated receiver node in a computer network, e.g., a voice over IP network. The RESV proxy can detect an RSVP Path message and determine whether a RESV message is appropriate for the anticipated traffic flow. If it is so determined, the RESV proxy generates and communicates a RESV message through the network back to the anticipated sender node. The appropriateness of a RESV message can be based upon predetermined relationships or logic involving one or more of network parameters, transport parameters, and characteristics of the anticipated traffic flow, and other traffic flow attributes determined from analyzing the RSVP Path message.

Abstract: A processor architecture for processing data packets representing voice over Internet Protocol (VoIP) calls in a packet-switched network is disclosed. According to an embodiment, a VoIP processor executes a voice packet processing operating system that is configured to monitor or manipulate the packets at an IP layer, media layer and signaling layer of the call. The VoIP processor includes a plurality of independently callable primitive software functions that carry out low-level VoIP packet processing functions. The VoIP processor executes one or more application programs that selectively call one or more of the primitive software functions and are independent of any underlying protocols of the existing network, thereby isolating the application programs from low-level processing details. Further, techniques are described for modifying characteristics of VoIP traffic for the purpose of monitoring and directing the VoIP traffic through a network.

Abstract: A method and apparatus for performing load-based packet marking within a network is described. In one aspect, a first group of one or more packets of a data flow are marked with a first behavioral treatment value that directs devices within the network to treat the first group of one or more packets with a first quality of service treatment. The bandwidth that is currently being achieved for the flow within the network is determined based on data traffic within the network. Based on the achieved flow bandwidth within the network a second behavioral treatment value is then determined. Thereafter, a second group of one or more packets of the data flow is marked with a second behavioral treatment value that directs devices within the network to treat the second group of one or more packets with a second quality of service treatment. The process of dynamically marking the packets for a particular data flow may be performed multiple times.

Abstract: Techniques are described for aggregating multiple media packets to improve end-to-end bandwidth efficiency. The techniques include using an RTP aggregation protocol that is not sensitive to packet loss to aggregate multiple media packets under a single header. According to the RTP aggregation protocol, the single header for an aggregated media packet comprises a version field, a zero field, a sequence number field and a trunk ID field. The single header encapsulates the aggregated payload, which is an aggregation of Real-Time Protocol (RTP) segments. An RTP segment either has a compressed format or an uncompressed format. The uncompressed RTP segment includes the complete uncompressed RTP packet copied from the original User Datagram Protocol (UDP) packet. The compressed RTP segment includes the payload of the original RTP rather than the complete original RTP packet.

Abstract: A method and apparatus for communicating a COPS protocol policy to a non-COPS-enabled network device is provided. A COPS proxy is connected between a policy server and a non-COPS-enabled network device. The policy server is configured to communicate COPS protocol policies to the COPS proxy, which is, in turn, configured to translate the COPS protocol policy into a policy that is in accordance with a policy protocol that the non-COPS-enabled network device can receive and correctly interpret (“non-COPS protocol”). The translation of the policy utilizes a mapping database that delineates predetermined relationships between COPS protocol policies and the non-COPS protocol policies. More specifically, the mapping database can include relationships between COPS protocol policy information base variables, network device roles and characteristics, and non-COPS protocol parameters and associated values. Further, the COPS proxy can be configured to detect and reconcile policy conflicts for one or more network devices.

Abstract: A method and apparatus for communicating a COPS protocol policy to a non-COPS-enabled network device (i.e., a device or one or more interfaces included in the device) is provided. A COPS proxy is networked with a policy server and a non-COPS-enabled network device such that the COPS proxy can communicate with the policy server and the non-COPS-enabled network device. The policy server is configured to communicate COPS protocol policies to the COPS proxy, which, in turn, is configured to translate the COPS protocol policy into a policy that is in accordance with a policy protocol that the non-COPS-enabled network device can receive and correctly interpret (a “non-COPS protocol”). The translation of the policy utilizes a mapping database that delineates predetermined relationships between COPS protocol policies and the non-COPS protocol policies.

Abstract: A method and apparatus are provided for automatic reverse-direction or bi-directional quality of service treatment of network data flows. A network device located at the edge or border of a network, such as a router that is connected to another network, identifies a data flow originating within its network and directed outside the network, and having packets set with quality of service treatment values. Identified quality of service treatments may be IP precedence, DSCP marking of packets in the flow, an RSVP PATH message, etc. The network device creates and stores, in its local memory, values that uniquely identify the flow and that tell the device how to treat packets of the same flow that are transmitted in the opposite or inbound direction. Upon identifying a corresponding inbound flow with quality of service treatment, all packets of the flow are given a pre-configured quality of service treatment based upon the quality of service treatment of the originally identified flow.

Abstract: A method and apparatus for providing RSVP capability for senders that either cannot or do not initiate RSVP processes is provided. An RSVP proxy is connected between a sender device and a receiver device on a computer network. The RSVP proxy detects a new traffic flow and determines whether an RSVP PATH message is appropriate for the traffic flow. If it is so determined, the RSVP proxy generates and communicates the RSVP PATH message through the network to the receiver device. The appropriateness of an RSVP PATH message can be based upon predetermined relationships or logic involving one or more of network parameters, transport parameters, and characteristics of the traffic flow, whether another RSVP signal is detected associated with the traffic flow, and other traffic flow attributes determined from decoding the traffic flow packets. The RSVP proxy can also interface with a policy server on the network to facilitate generation of the RSVP PATH message according to one or more of the traffic flow attributes.

Abstract: A method and apparatus for storing policies for use in policy-based management of quality of service treatments of network data traffic flows are described. The policies are stored in the form of policy statements. Each policy statement applies to a specific application that runs in the network. Policy statements are stored in a Repository, which may be a Directory Server or an X.500 directory. A policy server may create and store policies in the Repository based on information about the application, the network devices, and the quality of service treatments that the network devices can apply to a traffic flow. An application program and the policy server network device can retrieve the policy information from the Repository using appropriate function calls or an access protocol such as LDAP.

Abstract: A method and apparatus for policy-based management of quality of service treatments of network data traffic flows by integrating policies with application programs are described. In one embodiment, a quality of service value is selectively associated with a flow of information generated by an application program and directed to a network device. Mappings representing an abstract policy and associating a pre-determined network quality of service with a traffic flow type of the flow of information and with an application program are created and stored in a repository that is accessible by the application program. The mappings are converted into one or more settings of the network device. The policy is enforced at the network device in response to receiving traffic from the application program that matches the traffic flow type. The settings may be Differentiated Services Code Points or may be RSVP+ messages. Policies may be represented by statements stored in a directory schema.

Abstract: A method and apparatus for storing policies for use in policy-based management of quality of service treatments of network data traffic flows are described. The policies are stored in the form of policy statements. Each policy statement applies to a specific application that runs in the network. Each policy statement includes a condition and a network service to be applied to all traffic matching the condition. Each condition comprises one or more basic condition components connected by operators. Each basic condition comprises a basic policy parameter identifier, an operator and an operand. Policy statements are stored in a Repository, which may be a Directory Server or an X.500 directory. A policy server may create and store policies in the Repository based on information about the application, the network devices, and the quality of service treatments that the network devices can apply to a traffic flow.