HK1056290A - Method for providing ip telephony with qos using end-to-end rsvp signaling - Google Patents

Description

Method for providing quality of service to an internet protocol telephone using end-to-end resource saving protocol signaling

The present invention relates generally to the field of IP communications, and more particularly to a method for providing quality of service (QoS) to Internet Protocol (IP) phones using end-to-end resource reservation protocol (RSVP) signaling.

The internet society is moving towards a day to allow all forms of inter-personal communication to take place over the internet. Video broadcasting, radio transmission, computer data and telephony systems will be incorporated into one medium and transmitted all over the world without any perceived loss of quality.

However, to be commercially viable, IP communications such as IP telephony and other IP communication services will require a quality of service (QoS) equal to or higher than that provided by current digital circuit switched networks. This requires end-to-end QoS in the overall IP network and throughout the IP backbone that carries traffic between end networks. Although QoS is available, it requires the use of network resources, so if authorization and payment are supported in the domain where the communication takes place, the service provider will only guarantee QoS.

Various protocols and services have been developed to handle various aspects of IP communications. For example, Session Initiation Protocol (SIP) was developed for call setup; open Settlement Protocol (OSP) was developed for authorization and usage reporting; developing a common outside contract policy service (COPS) for policy deployment in network components; the resource reservation protocol (RSVP) was developed for setting QoS at the end network; a subnet bandwidth manager was developed for setting RSVP enabled QoS in 802.x form LAN; differentiated services (DiffServ) has been developed for setting QoS traffic classes in the IP backbone.

To complete a telephone call over the internet, at least three things occur. First, the called party must be prompted; second, a connection between callers must be established; finally, resources must be set aside for the call to connect to the caller. To this end, SIP is responsible for establishing sessions, while RSVP is responsible for reserving resources required for calls.

QoS is provided for IP communications across the internet, which requires a common way of call setup, authorization, and use of QoS. Although the various protocols described above have been developed in detail, there is currently no reported method on how to use them together in a consistent manner across the internet. Furthermore, there has been no reported method of dynamically establishing QoS policies for SIP-based voice and video calls over the internet.

It is therefore an object of the present invention to provide a method for providing QoS to IP phones using end-to-end RSVP signaling that is capable of providing acceptable QoS during IP communications across the internet.

It is another object of the present invention to provide a method for dynamically establishing QoS policies for SIP-based voice and video calls over the internet.

It is a further object of the present invention to provide a method for providing QoS to IP phones using end-to-end RSVP signaling that uses network resources efficiently and is easy to implement.

To achieve these objects, a method for providing QoS to an IP phone using end-to-end RSVP signaling is provided that includes transmitting a unique sequence of messages before, during, and after an IP communication. The sequence is not arbitrary, as the parameters transmitted in the previous message can be used in the subsequent message. Although the protocols listed above have been described and understood in many documents when used alone. But the situation is different when they are used together.

The present invention discloses a method whereby different protocols are used simultaneously to establish, maintain and tear down internet communications with acceptable QoS. This may be accomplished by dynamically establishing RSVP policies based on SIP telephony requests. Although the present invention focuses on the use of RSVP for end-to-end signaling of QoS subscriptions, the concept can be extended to any end-to-end subscription protocol. In addition, the same concept is also applicable to dynamically establishing a DiffServ policy based on SIP telephony requests, where the policy is provisioned on a real-time basis to a router (PUSH), rather than a router (PULL) that queries the policy.

These and other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a reference model for IP telephony communication;

fig. 2 is a call flow diagram illustrating call setup request, authorization and policy settings in accordance with the present invention;

FIG. 3 is a call flow diagram illustrating QoS establishment and completion of an IP telephony call in accordance with the present invention;

FIG. 4 is a call flow diagram illustrating RSVP tear down signaling and QoS resource release in accordance with the present invention;

fig. 5 is a call flow diagram illustrating QoS usage reported to a switching center (clearinghouse) in accordance with the present invention;

FIG. 6 is a call flow diagram illustrating call teardown with background usage update in accordance with the present invention; and

fig. 7 is a call flow diagram illustrating call teardown with real-time usage updates in accordance with the present invention.

Referring now to the drawings, in which like reference characters designate like or identical parts throughout the several views. Fig. 1 shows a schematic diagram of a reference model for telephone type IP communication. The reference model is chosen to represent many situations in IP telephony or other types of IP communications. It is not an exhaustive model but is used to define the message exchange between the network and the network elements.

The reference model of FIG. 1 has two types of customers: 1) at least one analog or digital telephone 110, 111 connected to an IP network through a circuit-switched network 100, 101(PBX) and an IP telephony Gateway (GWY)135, 136; and 2) at least one IP client such as IP phone 115 or various types of computers 130. Here, IP telephony gateways 135, 136, IP telephone 115, and computer 130 are all considered clients of SIP call setup and network resource RSVP signaling.

Internet Service Providers (ISPs) 120, 121 provide access to the IP backbone 190, while circuit-switched telephone Local Exchange Carriers (LECs) and private branch exchanges (PBXs) provide access to the IPs 100, 101. The physical connection between the ISP, PBX and IP telephony gateway may be any suitable media. Typically, most internet traffic is carried over optical cables, coaxial cables, and twisted pair wires. Policy servers 140, 141, and 142 use COPS for policy deployment in their respective elements. COPS is a query and response protocol that may be used to exchange policy information between a policy server and its clients. The term "policy" specifies a combination of rules defining network resource access and usage criteria. In addition, COPS RSVP capable routers R and R + 160, 170 are also located in their respective networks to route network traffic. SIP Proxy Servers (SPS)150, 151 act as Policy Enforcement Points (PEPs) authorizing calls requested by SIP clients 110, 111, 115 and 130.

The switching center server (CH)180 provides QoS to several functions related to call setup. In particular, the clearinghouse server 180 acts as a trust broker between a large number of network providers, IP telephony optional gateway location services, authorization of QoS (similar to credit card authorization in commerce), usage report collector, and a means of settlement between service providers. All of the above network components operate together to establish, maintain and terminate telephone calls over the internet. Each network element responds to a unique set of messages and commands.

Although the message exchanges of the above listed protocols are illustrated and understood in many separate files, the situation is different when used with all network elements.

Referring to fig. 2, the call flow diagram of fig. 2 illustrates call setup request, authorization, and policy setting in accordance with the present invention. Typically, call setup requests, authorization and policy settings occur as follows:

a) the SIP client (phone) 115 requests the SIP1 proxy server 150 to establish a call;

b) SIP1150 checks the local policy server POL 1140;

c) the local policy server POL 1140 checks with the switching center server CH 180;

d) SIP1150 requests to establish a call to remote SIP 2152;

e) SIP 2151 checks the local policy server POL 2141;

f) the local policy server POL 2141 checks with the switching center server CH 180;

g) the remote policy server POL2 provides policies in the edge routers R2161 and SIP2152 for use in local policy control;

h) if so, the local SIP1150 obtains a positive call progress report from the remote SIP 2152;

i) POL 1140 provides local policy in edge router R1160 and proxy SIP 1150; and

j) SIP1150 notifies phone 115 of the progress of the call.

The actual message sequence belongs to several protocols: SIP, OSP, COPS, RSVP, and SBM. The sequence is described in detail in fig. 2.

SIP phone 115 initiates the session and requests QoS by sending SIP INVITE message 1 to proxy server SIP 1150. Subsequently, the SIP1150 sends a COPS REQ AAA (authentication, authorization and accounting) message 2 to the local/client policy server POL 1140. Upon receiving message 2, the local policy server POL 1140 sends an OSP authorization request authentication request AUTHREQ message 3 to the switching center server CH 180. The switching center server CH180 responds by sending an OSP grant response AUTHRSP message 4 back to POL 1140. The AUTHRSP message 4 includes an authorization token for use in call setup.

POL 1140 then sends COPS DEC (decision) setup message 5 to SIP1150 and embeds the authorization token in the message. SIP1150 requests to establish a call with remote SIP2 by generating a SIP invite message 6 requesting QoS and sending message 6 to SIP 2152. Upon receiving the INVITE message 6, SIP2152 sends a COPS REQ AAA message 7 to policy server 2 POL 2141. The message 7 also contains an authorization token. Messages 8, 9 and 10 are identical to messages 3, 4 and 5, but are performed remotely.

SIP2152 then invites GWY 136 by sending SIP INVITE message 11 requesting QoS. GWY 136 replies to and replies with SIP183 message 12 that QoS is required. The SIP183 message indicates the session progress. SIP2152 signals policy server POL2 with a COPS REQ LDP (local decision policy) request message 13. POL 2141 provides policy in edge router R2161 and SIP2152 for use in local policy control by sending COPS DEC setup message 14 to R2161 and receiving COPS RPT (report) message 15 from R2161 when setup is successful. POL 2141 sends a COPS DEC setup message 16 to SIP2152 to establish policies in SIP 2151. When the remote provides the policy, SIP2152 sends SIP183 message 7 to SIP1150 indicating a positive call progress at the remote. Messages 18-21 are the same as messages 13-16 and the policy is provided in edge router R1 and SIP 1150. Finally, SIP1150 informs SIP client phone 115 of the progress of the call by sending SIP183 message 22.

At this point, the SIP, OSP, and COPS protocols are used to establish call requests, authorize calls, and establish policies for calls. However, there is the possibility that: although a call is successfully established using SIP, the call will suffer from a less than acceptable quality due to resource limitations that are not discovered until after the call is established. The present invention solves this problem by dynamically establishing QoS policies for SIP-based voice and video calls, as described below.

Referring now to fig. 3, the call flow diagram of fig. 3 illustrates QoS establishment, resource reservation, and completion of an IP telephony call in accordance with the present invention. In general, QoS setup and completion of an IP telephony call occurs in the following manner:

a) the SIP client 115 requests network resources for QoS using RSVP. At the edge router, the QoS of the flow is enforced by local policy control. SIP outside contract requests to provide a specific policy;

b) remote edge router R2161 establishes QoS in a remote Local Area Network (LAN) using SBM, and informs R1160, the LAN including at least one SIP client device;

c) r1160 establishing QoS in the LAN using SBM;

d) validating the LAN QoS subscription end-to-end in one direction;

e) repeating the same messages in steps (a) - (d) in the reverse direction;

f) the call progress is confirmed as "ringing" and answered;

g) establishing a bidirectional RTP (real-time transport protocol) stream; and

h) each party can place a call and make a telephone conversation.

The sequence will now be described in detail. With continued reference to fig. 3. Messages 23-31 establish the call flow from the caller to the callee and messages 32-40 establish the call flow from the callee to the caller. Finally, messages 41-46 confirm the call progress and answer the confirmation.

The SIP client phone 115 initiates a request for network resources by sending an RSVP PATH message to the edge router R1160. The RSVP PATH message is an operation sent by the sender to the receiver requesting a reservation. It follows the same route as the subscribed data flow will follow. Instead of requiring the edge router R1151 to request a policy decision from the policy server POL1, the resource request is sent directly to the edge router R1160. Thus, QoS is established directly in R1160 and decision-related policies are enforced by local policy control. Remember that the specific policies of the flow were previously provided by SIP external contract requests.

Edge router R1160 forwards message 23 to remote edge router R2161 as message 24. The edge router R2161 establishes QoS in the local area network LAN by SBM by sending RSVP PATH message 25. The PATH message requests resource reservation. GWY 136 informs edge router R1160 of the setup by sending RSVP RESV message 26 to edge router R1160. The RSVP RESV message reserves resources along the path between each device. This message is forwarded to edge router R1160 in the form of message 27. Edge router R1160 then begins establishing QoS in the LAN using SBM by issuing RSVP RESV message 28. The peer then confirms the LAN QoS reservation in one direction using RSVP RESV-CONF messages 29, 30 and 31. Resource reservation for QoS is established in the reverse direction using the same message format as in the forward direction. Specifically, messages 32-34 correspond to message 23, messages 35-37 correspond to message 26, and messages 38-40 correspond to message 29.

Finally, the call progress is confirmed as "ringing" and the confirmation is answered. To accomplish this, a SIP 200OK message 41 is sent from GWY 136 to SIP2152, modified, sent as message 42 to SIP1150, and delivered as message 43 to SIP client 115. The reply is organized by sending a SIP ACK message 44 from the client 115 to the SIP 1150. The message is modified and sent as message 45 to SIP 2152. Finally, a SIP ACK message 46 is sent from SIP2152 to GWY 136.

Upon receipt of the ACK message 46, a bi-directional RTP stream is established and parties can begin a telephone conversation, with QoS supported by resource reservations.

Referring to fig. 4, the call flow diagram of fig. 4 illustrates RSVP tear down signaling and release of QoS resources. After the call is setup and the RSVP has been established, any user can signal to the RSVP to release the QoS resources and tear down the QoS. Although media traffic (phone calls) may continue through the network, resource reservations are no longer guaranteed for QoS purposes. Typically, the message exchange occurs as follows:

a) the client sends a PATHTEAR message. PATHTEAR propagates to the remote gateway 136;

b) offloading QoS by edge router R1160 in the local LAN;

c) the local accounting report of policy deletion is provided by the edge router R1160 to the policy server POL1 and this report is also used when real-time usage reporting is required.

d) RSVP path teardown is signaled to the remote gateway 136;

e) the remote accounting reports are provided by the edge router R2162 to the policy server POL 2;

f) releasing QoS resources in the remote LAN; and

g) the edge router R2 provides remote accounting reports to the policy server POL 2.

The message exchange is described in detail in fig. 4. The teardown is initiated when SIP client phone 115 sends RSVPPATHTEAR message 401 to router R1160. The PATHTEAR message requests the disassembly of the reserved resource. PATHTEAR message 401 then propagates as message 402 to remote router R2162 and terminates as message 403 at gateway GWY 136. The PATHTEAR message is sent by the sender to the receiver and indicates that the data stream is terminated. Router R1160 then sends accounting report message 404 to policy server POL 1140. At the same time, a PATHTEAR message 405 is generated and sent to SIP phone client 115, and a RESVTEAR message 406 is sent to router R2161 and GWY 136. The RESVTEAR message actually deletes the reserved resources. Subsequently, the router R2 sends an accounting report message 407 to the policy server POL 2141. Finally, R2 sends a path message 408 to router R1160 and SIP phone client 115 and a RESVTEAR message 409 to GWY 136. At the conclusion of the message exchange, the RSVP is offloaded and the QoS resources are released. The call can continue but no longer guarantees resource reservation for QoS purposes.

Referring to fig. 5, the call flow diagram of fig. 5 illustrates a generic QoS usage report to a switching center. Remember that as mentioned above, the switching center server CH180 has several functions including being a usage report collector and being a settlement means between service providers.

The use of the SIP client phone 115 is first reported by the policy server POL 1140 to the switching center server CH180 in the form of message 501 and then acknowledged in the form of message 502. Remote usage is reported by the policy server POL 2141 to the switching centre CH180 in a similar manner in the form of a message 503 and acknowledged in the form of a message 506.

The common teardown of QoS and reported-of-use resources shown above is typically associated with internet telephone call termination. More complex message exchanges are shown in fig. 6 and 7.

Referring to fig. 6, the call flow diagram of fig. 6 illustrates call teardown with background usage update. After the telephone call is completed, the users speak each other and hang up. This event triggers a network resource release and may initiate the generation of a usage report for subsequent billing. The usage report may be generated independently of the call and QoS teardown (fig. 6), or concurrently with the call and QoS teardown (fig. 7). The latter may support instant billing settlement but add OSP usage reporting messages to the teardown message exchange.

Call teardown is initiated when SIP client phone 115 sends SIP BYE message 601 to SIP 1150. This message is propagated to GWY 136 in the form of messages 602 and 603. SIP150 sends a 200OK message 604 to SIP client 115 acknowledging the BYE message 601. Subsequently, the SIP1150 issues COPS REQ noLDP (delete local decision policy) message 605 and deletes the local decision policy from the LAN and router R1160 through COPS DEC Rem (COPS delete decision) message 606. A usage report RPT message 607 is generated and sent to the policy server POL 1. POL 1140 sends COPS DEC message 608 to SIP1150 and deletes the policy from SIP 1150. The RSVP path tear down is signaled from router R1160 to the remote gateway 136 using RSVP PATHTEAR message 609. With RSVP RESVTEAR message 610 and RSVP PATHTEAR message 611, resources are released and path teardown is signaled. Message 612 deletes the network resource and is similar to message 610. Messages 613 and 614 are SIP 200OK messages indicating success and are sent from GWY 136 to SIP2152 and forwarded to SIP 1150. Messages 615-. Finally, the SIP 200OK message 23 indicates success. The report messages 607 and 617 are later used for billing and checkout.

Usage reporting may also occur in real time. Referring to fig. 7, fig. 7 illustrates real-time usage accounting. The process is the same as in fig. 6 except for steps 701 and 702 of the client and steps 703 and 704 of the remote end. Message 701 is an OSP < use indication > message indicating, among other parameters, the message ID, duration, and destination. Message 702 is an OSP < use confirm > message and confirms the previously provided information.

While several embodiments of the present invention have been shown and described, it is to be understood that many changes and modifications may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (9)

1. A method of providing quality of service (QoS) in an Internet Protocol (IP) telephony session between a calling party and a called party, comprising the steps of:

communicating IP media for the session between the caller and an IP-capable first device;

communicating IP media for the session between the called and an IP-capable second device; and

establishing an IP connection between the first device and the second device; and

network resources are reserved for the telephony session.

2. The method of claim 1, wherein said first and said second devices are routers.

3. The method of claim 1, wherein said step of reserving network resources uses resource reservation protocol (RSVP).

4. The method of claim 1, wherein said step of reserving network resources further comprises the steps of:

generating, by a SIP client, a first Session Initiation Protocol (SIP) call setup request having a QoS;

transmitting the first call setup request to a first SIP proxy server;

generating, by the first SIP proxy server, a second SIP call setup request with QoS to a second SIP proxy server;

generating, by the second SIP proxy server, a third SIP call setup request with QoS to a remote client;

providing a policy in the second device and the second SIP proxy server;

providing a policy in the first device and the first SIP proxy server upon successful provision of the policy in the second device and the second SIP proxy server; and

notifying the SIP client of the call progress.

5. The method of claim 1, further comprising the steps of:

generating, by the SIP client, a first SIP call setup request having a QoS;

transmitting the first call setup request to a first SIP proxy server;

generating, by the first SIP proxy server, a second SIP call setup request with QoS to a second SIP proxy server;

generating, by the second SIP proxy server, a third SIP call setup request with QoS to a remote client;

providing, by a remote policy server, policies in the second device and the second SIP proxy server;

providing, by a client policy server, a policy in the first device and the first SIP proxy server upon successful provision of the policy in the second device and the second SIP proxy server; and

notifying the SIP client of the call progress.

6. The method of claim 4, further comprising the steps of:

establishing a QoS in a remote Local Area Network (LAN) with a remote Subnet Bandwidth Manager (SBM) and the second device;

notifying said first device of said QoS establishment in said remote LAN;

establishing QoS in the customer LAN using the customer SBM and the first device;

confirming and answering the call progress; and

a real-time transport protocol (RTP) stream is established.

7. The method of claim 6, comprising the steps of:

propagating RSVP PATHTEAR message to remote gateway to request deletion of QoS in the client LAN;

offloading QoS in a client LAN with the first device;

propagating RSVP PATHTEAR a message to the remote gateway to request deletion of QoS in the remote LAN; and

offloading QoS in a remote LAN using the second device.

8. The method of claim 7, further comprising the steps of:

generating, by the first device, a first usage report to a first policy server; and

generating, by the second device, a second usage report to a second policy server, wherein the usage report is for billing purposes.

9. The method of claim 4, further comprising the steps of:

checking a first policy server to determine a correct policy, wherein the checking is performed by the first SIP server;

checking a clearinghouse server to determine a correct policy and requesting authorization of the policy, wherein the checking and requesting are performed by the first policy server;

notifying the first policy server of the correct policy and providing authorization for the policy;

checking a second policy server to determine a correct policy, wherein the checking is performed by the second SIP server;

checking the clearinghouse server to determine the correct policy and requesting authorization of the policy, wherein the checking and requesting are performed by the second policy server; and

notifying the second policy server of the correct policy and providing authorization for the policy.