AU1361301A

AU1361301A - Method for providing ip telephony with qos using end-to-end rsvp signaling

Info

Publication number: AU1361301A
Application number: AU13613/01A
Authority: AU
Inventors: Steven R. Donovan
Original assignee: MCI Worldcom Inc
Current assignee: Verizon Business Global LLC
Priority date: 1999-11-05
Filing date: 2000-11-06
Publication date: 2001-06-06
Anticipated expiration: 2020-11-06
Also published as: MXPA02004490A; CN1421103A; WO2001035604A2; EP1230806A2; JP2003514446A; WO2001035604A3; CA2390168A1; BR0015350A; EP1230806A4; AU776055B2

Description

WO 01/35604 PCT/USOO/30446 METHOD FOR PROVIDING IP TELEPHONY WITH QoS USING END-TO- END RSVP SIGNALING The present invention relates generally to the field of IP communication. and more 5 particularly to a method for providing Internet Protocol (IP) telephony with quality of service (QoS) using end-to-end Resource Reservation Protocol (RSVP) signaling. The Internet community is working toward one day having all forms of interpersonal communication carried over the Internet. Video broadcasts. radio transmissions. computer 10 data and telephone systems will merge into one medium and be transported anywhere in the world without any loss of perceived quality. In order to be commercially practicable however. IP communications such as IP telephony and other IP communication services will require a quality of service (QoS) equal 15 to or better than that currently available on digital circuit switched networks. This requires end-to-end QoS in corporate IP networks and across the IP backbones that carry traffic between the end networks. While QoS is available, it requires the usage of network resources and therefore. service providers will only ensure QoS if authorization and payments are supported across the domains where the communications are taking place. 20 Several protocols and services have been developed to handle the various aspects of IP communications. For instance. Session Initiation Protocol (SIP) was developed for call setup: Open Settlement Protocol (OSP) was developed for authorization and usage reporting: common Outsourcing Policy Service (COPS) was developed for policy deployment in 25 network elements: Resource Reservation Protocol (RSVP) was developed for setting up QoS in end networks: Subnet Bandwidth manager (SBM) was developed for setting up RSVP WO 01/35604 PCT/USOO/30446 initiated QoS in 802.x style LANs; and Differentiated Services (DiffServ) was developed for setting up QoS traffic classes in IP backbones. In order to complete a phone call on the Internet, at least three things should occur. 5 First. the called party has to be alerted. Second, the connection between the callers must be established, and finally, resources to connect to callers may have to be set aside exclusively for the conversation. To this end, SIP is responsible for establishing the session while RSVP is responsible for reserving the resources necessary for a call. 10 Providing IP communications with QoS across the Internet requires a common way of usage for call setup. authorization, and QoS. Though the individual protocols above have been developed in detail. there is currently no reported method on how to use the individual protocols together in a consistent way across the Internet. In addition, there are no reported methods for dynamically establishing QoS policy for SIP-based voice and video calls on the 15 Internet. It is therefore an object of the present invention to provide a method for implementing IP telephony with QoS using end-to-end RSVP signaling that is capable of providing an acceptable QoS during a IP communications across the Internet. 20 It is another object of the invention to provide a method for dynamically establishing QoS policy for SIP-based voice and video calls on the Internet. It is an additional object of the invention to provide a method for implementing IP 25 telephony with QoS using end-to-end RSVP signaling that is efficient in its use of network resources and easy to implement.

WO 01/35604 PCTIUSOO/30446 To achieve these objects. there is provided a method for implementing IP telephone with QoS using end-to-end RSVP signaling that comprises the transfer of a unique sequence of messages prior to, during, and after IP communications. The sequence is not arbitrary as 5 the parameters communicated in a previous message may be used in the follow-up messages. While the message exchanges for the protocols listed above are well documented and understood when each is used in isolation. this is not the case when they are used together. The present invention discloses a method whereby the separate protocols are used 10 together to setup, maintain, and teardown Internet communications having an acceptable QoS. This is accomplished by dynamically establishing RSVP policy based on SIP telephony requests. While the present invention focuses on the use of RSVP for end-to-end signaling of QoS reservations, the concepts can also be extended for use with any end-to-end reservation protocol. In addition. the same concept also applies to dynamically establishing DiffServ 15 policy based on SIP telephony requests wherein the policy is provisioned on a real time basis to the router (PUSH) instead of the router querying for the policy on a real time basis (PULL.) These and other objects and features of the present invention will become apparent 20 from the following detailed description considered in connection with the accompanying drawings in which: FIG. 1 is a schematic view of a reference model of IP telephony communication; 25 FIG. 2 is a call flow diagram illustrating a call setup request, authorization and policy installation in accordance with the present invention: 3 WO 01/35604 PCT/US0O/30446 FIG. 3 is a call flow diagram illustrating a QoS setup and completion of the IP telephone call in accordance with the present invention: 5 FIG. 4 is a call flow diagram illustrating an RSVP teardown signaling and release of QoS resources in accordance with the present invention; FIG. 5 is a call flow diagram illustrating a QoS usage reporting to a clearinghouse in accordance with the present invention: 10 FIG. 6 is a call flow diagram illustrating a call teardown with background usage update in accordance with the present invention; and FIG. 7 is a call flow diagram illustrating a call teardown with real-time usage update 15 in accordance with the present invention. Referring now to the drawings. in which similar reference characters denote similar or identical elements throughout the several views, FIG. 1 shows a schematic diagram of a reference model for IP communication of the telephony type. The reference model has been 20 chosen to represent many instances found in IP telephony or other types of IP communications. It is not, however. an exhaustive model. but rather serves the purpose of definingz the message exchange between networks and network elements. The reference model of FIG. I has two types of clients: 1) at least one analog or 25 digital phone 1 10. 111 that connects to the IP network via a circuit switched network 100, 101 (PBX) and IP telephony gateways (GWY) 135. 136: and 2) at least one IP client such as 4 WO 01/35604 PCT/USOO/30446 an IP phone 115 or various types of computers 130. Here. IP telephony gateways 135. 136. IP phones 115 and computers 130 are considered clients for SIP call setup and RSVP signaling for network resources. 5 Internet Service Providers (ISPs) 120. 121 provide access to an IP backbone 190 while the local exchange carrier (LEC) for circuit switched telephony and the private branch exchange (PBX) provide access to the IPSs 100, 101. The physical connections between the ISPs. PBXs. and the IP telephony gateways can be any suitable media. In general, most of the Internet traffic travels over fiber optic cable. coax cable and twisted pair wire. Policy 10 servers 140. 141. and 142 use COPS for policy deployment in their respective elements. COPS is a query and response protocol that can be used to exchange policy information between a policy server and its clients. The term "policy" refers to a combination of rules defining criteria for network resource access and usage. In addition. COPS RSVP capable routers R and R+. 160 and 170. are similarly situated in their respective networks to route 15 network traffic. SIP proxy servers (SPS) 150. 151 act as policy enforcement points (PEP) to authorize calls requested by SIP clients 110, 111, 115 and 130. A Clearing House server (CH) 180 serves several functions pertinent to call setup with QoS. In particular. clearing house server 180 acts as a trust broker between a large 20 number of network providers. an optional gateway location service for IP telephony, an authorization for QoS (similar to credit card authorization in commerce), a collector of usage reports. and as a means of settlement between service providers. All of the above network elements operate together to setup, maintain and close a telephone conversation on the Internet. Each network element responds to a unique set of messages and commands. 25 5 WO 01/35604 PCT/USOO/30446 While the message exchanges for the protocols listed above are well documented and understood separately. when used together with all of the network elements. this is not the case. 5 Referring to FIG. 2. there is shown a call flow diagram illustrating a call setup request. authorization and policy installation according to the present invention. In general, the call setup request. authorization and policy installation occur as follows: a) a SIP client (phone) 115 requests call setup from a SIPI proxy server 150; 10 b) SIPI 150 checks a local policy server POL1 140: c) Local policy server POL l 140 checks with a clearing house server CH 180; d) SIP1 150 requests call setup from a remote SIP2 152; e) SIP2 151 checks a local policy server POL2 141; f) Local policy server POL2 141 checks with clearing house server CH 180; 15 g) Remote policy server POL2 provisions policy for use by local policy control in edge router R2 161 and SIP2 152: h) If OK. local SIP1 150 gets positive call progress report from remote SIP2 152; i) Local policy is provisioned by POLl 140 in edge router RI 160 and proxy 20 server SIP1 150: and j) SIP1 150 informs phone 115 of call progress. The actual sequence of messages belongs to several protocols: SIP, OSP, COPS, RSVP and SBM. The sequence is described in detail in FIG. 2. 25 6 WO 01/35604 PCT/USOO/30446 SIP phone 1 15 initiates a session by sending an SIP INVITE message I to proxy server SIP 1150 and requests QoS. SIP 1150 then sends a COPS REQ AAA (authentication, authorization. and accounting) message 2 to local / client policy server POL1 140. Upon receipt of message 2. local policy server POL1 140 sends an OSP authorization request 5 authentication request AUTHREQ message 3 to clearing house server CH 180. Clearing house server CH 180 responds by sending an OSP Authorization response AUTHRSP message 4 back to POL l 140. AUTHRSP message 4 includes an authorization token for use with call setup. 10 POL 1 140 next sends a COPS DEC (decision) install message 5 to SIP1 150 with the authorization token embedded in the message. SIP1 150 requests call setup with remote SIP2 by generating an SIP INVITE message 6 requesting QoS and sending message 6 to SIP2 152. Upon receipt of INVITE message 6, SIP2 152 issues COPS REQ AAA message 7 to policy server 2 POL2 141. Message 7 also contains the authorization token. Messages 8, 9 and 10 15 are identical to messages 3, 4, and 5 but performed at the remote end. SIP2 152 then invites GWY 136 by sending an SIP INVITE message I 1 that requests QoS. GWY 136 answers with an SIP 183 message 12 and echos that QoS is required. A SIP 183 message signifies session progress. SIP2 152 signals policy server POL2 using a COPS 20 REQ LDP (local decision policy) request message 13. POL2 141 provisions policy for use by local policy control in edge router R2 161 and SIP2 152 by sending a COPS DEC install message 14 to R2 161 and receiving a COPS RPT (report) message 15 from R2 161 when the installation is successful. POL2 141 sends a COPS DEC install message 16 to SIP2 152 to install the policy in SIP2 151. When policy is provisioned in the remote end, SIP2 152 sends 25 a SIP 183 message 17 to SIP 1150 which signifies a positive call progression on the remote end. Messages 18 - 21 are identical to messages 13 - 16 and provision policy in edge router 7 WO 01/35604 PCTIUSOO/30446 R 1 160 and SIP1 150. Finally, SIP1 150 informs SIP client phone 115 of the call progress by sending, SIP 183 message 22. At this point. SIP. OSP and COPS protocols are used to setup a call request, authorize 5 the call and install policy for the call. There is however the possibility that the call. while setup successfully using SIP will experience less than acceptable quality due to resource limitations discovered after the call is set up. The present invention solves this problem by dynamically establishing QoS policy for SIP based voice and video calls on the Internet, as will be discussed below. 10 Referring now to FIG. 3. there is shown a call flow diagram illustrating QoS setup, resource reservation and completion of the IP telephone call according to the present invention. In general. the QoS setup and completion of the IP telephone call occur as follows: 15 a) SIP client 115 requests network resources for QoS using RSVP. At the edge router. QoS for the flow is enforced per the local policy control. The specific policy by the SIP outsourced request; b) Remote edge router R2 161 install QoS in remote Local Area Network (LAN) 20 using SBM and informs R1 160, the LAN comprises at least one SIP client device; c) R1 160 installs QoS in LAN using SBM: d) LAN QoS reservation is confirmed end-to-end in one direction; e) the same messages in steps (a)-(d) are repeated in the opposite direction: 25 f) Call progress is confirmed as "Ringing" and acknowledged back: g) Two-way RTP (real-time transfer protocol) streaming is established: and 8 WO 01/35604 PCT/US00/30446 h) The parties can say "hello" and have a phone conversation. The sequence is now described in detail. With continued reference to FIG. 3, messages 23 - 31 establish call flow from caller to callee, while messages 32 - 40 establish 5 call flow from the callee to the caller. Finally, messages 41 - 46 confirm the call progress and acknowledge the confirmation. SIP client phone 115 initiates the request for network resources by sending an RSVP PATH message to edge router R1 160. RSVP PATH message is an operation sent by the 10 sender to the receiver requesting a reservation. It follows the same route that the data flow of the reservation will follow. The request for resources is sent directly to edge router RI 160 rather than require edge router R 1161 to request a policy decision from policy server POL1. In this manner, QoS is installed directly in R1 160 and decisions concerning policy are enforced per the local policy control. Recall that the specific policy for the flow was 15 provisioned previously by the SIP outsourced request. Edge router R 1 160 forwards message 23 to remote edge router R2 161 as message 24. Edge router R2 161 installs QoS in the local area network LAN using the SBM by sending RSVP PATH message 25. The PATH message request recourse reservation. GWY 20 136 informs edge router R l 160 of the installation by sending RSVP RESV message 26 to edge router RI 160. RSVP RESV messages reserves resources along the paths between each device. This message is forwarded to edge router R1 160 in the form of message 27. Router R I 160 then proceeds to install QoS in the LAN using the SBM by issuing RSVP RESV message 28. The LAN QoS reservation is then confirmed end-to-end in one direction using 25 RSVP RESV-CONF messages 29. 30 and 31. Resource reservation for QoS is established in the reverse direction using the same message formats as in the forward direction. 9 WO 01/35604 PCT/USOO/30446 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 acknowledged. To accomplish this. an SIP 200 OK message 41 is sent from GWY 136 to 5 SIP2 152, modified and sent to SIP 1150 as message 42 and delivered to SIP client 115 as message 43. The acknowledgment is orchestrated by sending a SIP ACK message 44 from client 115 to SIP 1150. The message is modified and sent to SIP2 152 as message 45. Finally, as SIP ACK message 46 is sent from SIP2 152 to GWY 136. 10 Upon receipt of ACK message 46. two way RTP streaming is established and the parties can begin the phone conversation with QoS supported by resource reservation. Referring to FIG. 4. there is shown a call flow diagram illustrating RSVP teardown signaling and the release of QoS resources. After a call is setup and RSVP has been 15 established, either user may signal RSVP to release the resources and teardown the QoS. While media traffic (phone call) can continue to traverse the network, it is no longer ,uaranteed resource reservation for QoS purposes. In general, the message exchange occurs as follows: 20 a) Client sends PATHTEAR message. PATHTEAR is propagated to remote gateway 136; b) QoS is de-installed by edge router R1 160 in local LAN; c) Local accounting report for removal of policy is provided by edge router RI 160 to policy server POL1. and this report is also used if real-time usage reporting is 25 needed: d) RSVP path teardown is signaled to remote gateway 136: 10 WO 01/35604 PCT/USOO/30446 e) Remote accounting report is provided by edge router R2 162 to policy server POL2; f) QoS resources are released in remote LAN: and g) Edge router R2 provides remote accounting report to policy server POL2. 5 The message exchange is described in detail in FIG. 4. The teardown is initiated when SIP client phone 115 sends an RSVP PATHTEAR message 401 to router R1 160. PATHTEAR messages request teardown of reserved resources. PATHTEAR message 401 is then propagated to remote router R2 161 as message 402 and terminates at gateway GWY 10 136 as message 403. The PATHTEAR message is sent by a sender toward a receiver and indicates that data flow is terminated. Router RI 160 then issues an accounting report message 404 to policy server POL1 140. 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 R2 161 and GWY 136. RESVTEAR messages actually remove reserved resources. Router 15 R2 then issues an accounting report message 407 to policy server POL2 141. Finally, R2 issues a PATHTEAR message 408 to router R1 160 and SIP phone client 115. and issues a RESVTEAR message 409 to GWY 136. At the conclusion of the message exchange. RSVP is uninstalled and QoS resources are released. The call can continue, but it is no longer guaranteed resource reservation for QoS purposes. 20 Referring to FIG. 5. there is shown a call flow diagram illustrating a generic QoS usage reporting to a clearinghouse. Recall that as set forth above, clearing house server CH 180 has several functions including, among others. acting as a collector of usage reports, and acting as a means of settlement between service providers. 25 11 WO 01/35604 PCT/USOO/30446 Usage by SIP client phone 115 is first reported by policy server POL 1140 to clearing house server CH 180 in message 501 and then confirmed in message 502. Remote usage is similarly reported by policy server POL2 141 to clearing house server CH 180 in message 503 and confirmed in message 506. The generic teardown of resources for QoS and usage reporting shown above is typically linked to the termination of the Internet phone call. The more complex message exchanges are shown in FIG. 6 and FIG. 7. 10 Referring to FIG. 6, there is shown a call flow diagram illustrating a call teardown with background usage update. Upon completion of the phone call, the users exchange parting words and hang up the phone. This event triggers the release of network resources and may initiate the generation of usage reports for subsequent billing. The usage reports can be generated either independent of the call and QoS teardown (FIG. 6) or contemporaneously 15 with the call and QoS teardown (FIG. 7). The latter option can support the instantaneous settlement of charges but adds OSP usage reporting messages to the teardown message exchange. The call teardown is initiated when SIP client phone 115 sends a SIP BYE message 20 601 to SIP 1150. The message is propagated to GWY 136 in the forms of messages 602 and 603. SIPs 150 sends a 200 OK message 604 to SIP Client 115 confirming the BYE message 601. SIP1 150 then issues a COPS REQ noLDP (remove local decision policy) message 605 and removes the local decision policy from the LAN and router RI 160 with a COPS DEC Rem (COPS remove decision) message 606. A usage report RPT message 607 is generated 25 and sent to policy server POL l. POL L 140 sends a COPS DEC message 608 to SIP1 150 and removes the policy from SIP 1 150. RSVP path teardown is signaled to remote gateway 136 12 WO 01/35604 PCT/USOO/30446 from router R1 160 using RSVP PATHTEAR message 609. Resources are released and path teardown is signaled using RSVP RESVTEAR message 610 and RSVP PATHTEAR message 611. Message 612 removes network resources and is similar to message 610. Messages 613 and 614 are a SIP 200 OK message indicating success and are sent from GWY 5 136 to SIP2 152 and forwarded to SIP1 150. Messages 615 - 622 accomplish the same tasks as messages 605 - 612 but occur at the remote router R2 161. Finally, SIP 200 OK message 23 indicates success. The report messages 607 and 617 are later used for billing to settle accounts. 10 Usage reporting may also happen in real time. Referring to FIG. 7, there is shown usage accounting in real time. The process is identical to FIG. 6 with the addition of steps 701 and 702 on the client side and steps 703 and 704 on the remote side. Message 701 is an OSP <Usage Indication> message and indicates message ID, duration and destination in addition to other parameters. Message 702 is an OSP <Usage Confirmation> message and 15 confirms the information previously supplied. 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 thereto without departing from the spirit and scope of the invention as defined in the appended claims. 20 13

Claims

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: transporting IP media for said session between said calling party and a first device 5 have IP capability; transporting IP media for said session between said called party and a second device having IP capability; and establishing an IP connection between said first device and said second device; and reserving network resources for said telephony session. 10

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

3. The method according to claim 1, wherein the step of reserving network resources 15 uses Resource Reservation Protocol (RSVP).

4. The method according to claim 1. wherein the step of reserving network resources further comprises the steps of: generating a first session initiation protocol (SIP) call setup request with QoS by an 20 SIP client; transporting said first call setup request to a fist SIP proxy server; generating a second SIP call setup request with QoS by said first SIP proxy server to a second SIP proxy server; generating a third SIP call setup request with QoS by said second SIP proxy server to 25 a remote client: provisioning policy in said second device and said second SIP proxy server; 14 WO 01/35604 PCT/USOO/30446 provisioning policy in said first device and said first SIP proxy server upon successful provisioning of policy in said second device and said second SIP proxy server: and notifying said SIP client of the call progress.

5 5. The method according to claim 1. further comprising the steps of: generating a first SIP call setup request with QoS by an SIP client; transporting said first call setup request to a first SIP proxy server; generating a second SIP call setup request with QoS by said first SIP proxy server to a second SIP proxy server: 10 generating a third SIP call setup request with QoS by said second SIP proxy server to a remote client; provisioning policy by a remote policy server in said second device and said second SIP proxy server; provisioning policy by a client policy server in said first device and said first SIP 15 proxy server upon successful provisioning of policy in said second device and said second SIP proxy server; and notifving said SIP client of the call progress.

6. The method according to claim 4. further comprising the steps of: 20 installing QoS in a remote local area network (LAN) using a remote subnet bandwidth manager (SBM) and said second device; informing said first device of said QoS installation in said remote LAN: installing QoS in a client LAN using a client SBM and said first device: confirming and acknowledging the call progress: and 25 establishing real-time transfer protocol (RTP) streaming. 15 WO 01/35604 PCT/USOO/30446

7. The method according to claim 6. further comprising the steps of: propagating an RSVP PATHTEAR message to a remote gateway to request removal of QoS in the client LAN: uninstalling QoS in client LAN using said first device; 5 propagating an RSVP RESVTEAR message to said remote gateway to request removal of QoS in the remote LAN: and uninstalling QoS in remote LAN using said second device.

8. The method according to claim 7. further comprising the steps of: 10 generating a first usage report by said first device to a first policy server: and generating a second usage report by said second device to a second policy server, wherein the usage reports are used for accounting purposes.

9. The method according to claim 4. further comprising the steps of: 15 checking a first policy server to determine correct policy, wherein said checking is performed by said first SIP server; checking a clearing house server to determine correct policy and to request authorization for the policy, wherein said checking and requesting is performed by said first policy server; 20 notifying said first policy server of the correct policy and providing authorization for the policy; checking a second policy server to determine correct policy, wherein said checking is performed by said second SIP server: checking said clearing house server to determine correct policy and to request 25 authorization for the policy. wherein said checking and requesting is performed by said second policy server: and 16 WO 01/35604 PCT/USOO/30446 notifying said second policy server of the correct policy and providing authorization for the policy. 17