CN101175293B - Call method using PUSH mode - Google Patents

Abstract

A calling method using the PUSH mode related to telecommunication technology, including reserving QoS resources and transmitting the QoS resource reservation result to the terminal during the call process, and the QoS resource reservation result is carried by the SIP protocol extension header field; The QoS resource reservation result is extended with the P-Media-Authorization header field; the process is: A. The calling terminal sends a message to the called terminal, which carries the information provided by the session description protocol; B. The called terminal responds with a message to the calling terminal. Agent, which carries the reply information of the session description protocol, C. The call agent completes the offer/reply matching, reserves QoS resources according to the matching result, and transfers the result to the calling or called terminal. The present invention enables the terminal to understand the QoS resources Whether it has been reserved successfully or not, the call flow of PUSH mode QoS resource reservation has been enhanced and perfected, which has strong practicability.

Description

Call method using PUSH mode

technical field

The invention relates to electric communication technology, in particular to a calling method using PUSH mode.

Background technique

The Quality of Service (QoS: Quality of Service) quality assurance system is applied to the Internet (Internet) technology, and there are many specific implementation methods. The simple method can be to equip the router with more memory, perform lossy or lossless compression on pictures, videos, audio files, etc., or implement HTTP compression on the web server, which can also solve the problem of bandwidth, but it will increase the number of servers. CPU burden. If these simple methods can't solve the problem, some complex strategies need to be adopted to realize QoS, such as service type (ToS: Type of Service), integrated service (IntServ: Integrated Services), differentiated service (DiffServ: Differentiated Services) Or traffic shaper (Traffic shaper) business.

Driven by real-time services such as broadband telephony or voice over IP (VoIP: Voice over IP), the Internet Engineering Task Force (IETF: Internet Engineering Task Force) proposed the IntServ model, which is a flow-based QoS mechanism. Strict control, providing strict QoS guarantee for applications, but it has scalability problems, because each router that the business flow passes must maintain a soft state for it, so IntServ cannot be applied on a large scale. In order to solve the scalability problem, IETF proposed the DiffServ model. DiffServ is a class-based QoS mechanism. It is relatively successful in deployment, but it can only provide relative QoS guarantee, especially when the bandwidth is not enough, it still cannot guarantee QoS.

In recent years, the session-based dynamic QoS control mechanism has gradually become a research direction. Under this architecture, the control plane perceives the QoS resources required by the session, performs admission control on the QoS resource requests required by the session, and completes the QoS resources requested by the session on the media plane. Enforcement of QoS policies approved by the plane.

For this session-based dynamic QoS control mechanism, many standard organizations are currently studying similar mechanisms, such as Internet Engineering Task Force IETF, International Telecommunication Union (ITU: International Telecommunication Union), Telecom and Internet Converged Services and Advanced Network Protocol (TISPAN: Telecommunications and Internet converged Services and Protocols for Advanced Networking), the third generation partnership project (3GPP: The 3rd Generation Partnership Project) and so on.

This session-based dynamic QoS control mechanism specifically includes two implementation modes of PULL and PUSH. The PULL mode and the PUSH mode are suitable for different application scenarios, and are not only related to terminal types, but also related to access networks.

The PULL mode has specific requirements for terminals, and requires terminals to support authorization tokens, which are classified according to the support for QoS. ITU describes the following three types of terminals:

1. Unaware of QoS, the terminal has no QoS interaction capability at the service layer and the transport layer. The terminal can initiate a service request, but it will not express the required QoS resources.

2. QoS awareness at the service layer. The terminal can express QoS resource requirements through service layer signaling, but it does not have the QoS negotiation capability at the transport layer.

3. Service and transport layer QoS awareness. In addition to the service layer QoS awareness capability, the terminal also supports the transport layer QoS negotiation protocol. For example, support RSVP (Resource Reservation Protocol, resource reservation protocol) or similar protocols, support layer 2 QoS awareness protocols, such as 802.1p, PDP Context, etc.

The terminal meeting the requirements of the PULL mode is the third type of terminal, that is, the terminal has the QoS capability of the service layer and the transport layer. But in fact, a large number of current user terminals are terminals of the second type. For service requests of such terminals, apply the PUSH mode shown in Figure 1 to reserve QOS resources, and the control process is as follows:

1) The terminal UA1 that does not support the QoS reservation signaling at the transport layer (such as RSVP) initiates a call INVITE (invites the user to join the call), and the SDP Offer carried in the request indicates the desired media channel type of the caller. The called terminal UA2 sends back 183 (200 response) Answer carrying the SDP.

2) The call agent determines the relevant attributes of the media channel according to the Offer/Answer, and authorizes and authenticates the QoS resources corresponding to the media channel to be established. After the authorization is passed, the corresponding QoS policy is directly issued to the border router for execution, and the border router immediately reserves corresponding resources for the specific media channel according to the QoS policy.

In the subsequent communication, when the media flow between the calling terminal UA1 and the called terminal UA2 passes through the border router, the corresponding QoS resource reservation has been obtained, and there is no need for the terminals UA1, UA2 and the border router to perform QoS resource reservation at the transport layer protocol interaction.

The PUSH mode requires each network device of the access network to support the PUSH interface with the application layer device (such as a call agent), so that the call agent can directly PUSH the QoS policy to each network device in the access network, and implement the QoS policy for a specific media stream. QoS resource reservation.

At present, each network device of the wireless access network usually supports the resource reservation protocol of the transport layer, so the QoS reservation defined by 3GPP is PULL mode, and the application of the fixed access network usually has the second type of terminal, so in TISPAN The QoS reservation process defined in the RACS architecture for the fixed access network is the PUSH mode.

The specific flow of the PUSH mode is shown in Figure 2, where:

Message 4-Message 7, after the call agent PROXY receives the 183 response from the called terminal UB, it completes the SDP Offer/SDP Answer matching, and interacts with the PDP to perform media authorization. It is delivered to the router ER for execution, which indicates which QoS resource is reserved for which media stream. Subsequently, the user terminals UA1 and UA2 can directly send and receive corresponding media streams.

Different from 3GPP's PULL mechanism, the resource reservation operation in PUSH mode is actively completed by network devices, and the terminal does not need to actively initiate the QoS resource reservation process at the transport layer through the obtained flag or token Token. Therefore, in PUSH mode, Terminals on the fixed access network cannot explicitly know whether corresponding QoS resources have been reserved successfully.

Contents of the invention

The purpose of the present invention is to provide a call method using the PUSH mode to overcome the shortcoming in the prior art that the terminal cannot know whether the QoS resources have been successfully reserved.

The call method using PUSH mode in the present invention is characterized in that: during the call process, it includes reserving QoS resources and transmitting the QoS resource reservation result to the terminal, and the QoS resource reservation result is passed through the SIP protocol extension header Domain carrying; wherein, including the following steps:

A. The calling terminal sends a message, and the call agent sends the message to the called terminal, which carries the provision information SDP Offer of the session description protocol;

B. The called terminal responds with a message to the call agent, which carries the reply information SDP Answer of the session description protocol;

C. The call agent completes the matching of Offer and Answer, reserves QoS resources according to the matching result, carries the QoS resource reservation result in the message, and transmits it to the calling or called terminal.

The beneficial effects of the present invention are: the present invention transmits the QoS resource reservation result to the terminal, and the QoS resource reservation result is carried through the SIP protocol extension header field, and the terminal can directly know whether the QoS resource has been reserved successfully, which overcomes the problem of the prior art The present invention expands the call signaling of the PUSH mode, and the QoS resource reservation result is carried through the SIP protocol extension header field (such as the P-Media-Authorization header field), and the call flow of the PUSH mode QoS resource reservation is carried out. Enhanced and perfected, the QoS resource reservation result is carried in the SIP message and notified to the user terminal.

Description of drawings

FIG. 1 is a schematic diagram of a network connection in the prior art PUSH mode;

FIG. 2 is a schematic diagram of a control flow in the prior art PUSH mode;

Fig. 3 is a schematic diagram of the basic control flow in the PUSH mode of the present invention;

Fig. 4 is a schematic diagram of a specific example control flow in the PUSH mode of the present invention;

Fig. 5 is a schematic diagram of a specific example control flow of the PUSH mode of the present invention;

FIG. 6 is a schematic diagram of another specific example control flow of the PUSH mode of the present invention;

Fig. 7 is a schematic diagram of the PreCondition control flow in the PUSH mode of the method of the present invention.

Detailed ways

Below according to accompanying drawing and embodiment the present invention will be described in further detail:

In the call process of the present invention, it includes reserving QoS resources and transmitting the QoS resource reservation result to the QOS resource reservation requester, and the QoS resource reservation result extends the header field through the Session Initiation Protocol (SIP: Session Initiation Protocol) carry.

As shown in Figure 3, the call agent (P-CSCF: Proxy-Call State Control Function) reserves QoS resources after the SDP Offer/Answer is matched, and sends the QoS resource reservation result to the offerer through the SIP message carrying the Answer instruct.

As shown in Figure 3, its basic control flow is as follows:

A) Message 1-Message 2: The terminal of the Offer party (that is, the calling terminal) sends a message to the terminal of the Answer party (that is, the called terminal), which carries the provision information SDP Offer of the Session Description Protocol;

B) Message 3: The terminal on the Answer side sends a response message to the call agent P-CSCF, which carries the reply information SDP Answer of the session description protocol;

C) Message 4: The call agent completes the offer/reply Offer/Answer match, reserves QoS resources according to the matching result, carries the QoS resource reservation result (QoS result indication) in the message, and delivers it to the terminal of the offerer.

There are many ways to express the result of QoS resource reservation. For example, the existing P-Media-Authorization (P-Media-Authorization) header field can be used to extend the parameters carried in this header field. By carrying The P-Media-Authorization header field carries "QoS resource reservation failure" or "QoS resource reservation success" to notify the terminal of the QOS resource reservation result.

As shown in Figure 4, there are two call agents P-CSCF1 and P-CSCF2 in the figure, which provide services for terminals UA1 and UA2 respectively (in the figure, UA1 initiates an SDP Offer, and UA2 sends back an SDP Answer).

In the example in FIG. 4 , it is reflected that the call agent reserves resources for the access side, and sends the resource reservation result of the access side to the terminal on the own side.

After receiving the Answer, the call proxy P-CSCF1 reserves QoS resources for the terminal UA1, and sends the reservation result to the terminal on the local side by carrying the "QOS resource reservation indication" in the SIP message carrying the Answer, that is, initiates the SDP Offer's terminal UA1.

After receiving the Answer, the call proxy P-CSCF2 reserves QOS resources for the terminal UA2, and at this time, it transmits a SIP message to the terminal UA1. Therefore, it cannot immediately notify the service terminal UA2 on its own side of the reservation result, and The reservation result is sent to the terminal UA2 through any SIP message sent by the terminal UA1 to the terminal UA2 carrying the "QOS resource reservation indication", that is, the terminal UA2 that returns the SDP Answer.

As shown in Figure 4, its basic control flow is as follows:

a) Message 1-Message 3: The terminal UA1 sends a SIP message carrying the offer information SDPOffer of the Session Description Protocol to the terminal UA2;

b) Message 4: The terminal UA2 sends a SIP message carrying the reply information SDP Answer of the session description protocol to the call agent P-CSCF2; P-CSCF2 uses the PUSH mode to reserve QOS resources for UA2 according to the SDP matching result. P-CSCF2 saves the reservation result of the QOS resource reservation made for UA2, and at this moment, it cannot notify UA2 of the result of resource reservation. P-CSCF2 continues to forward the SIP message carrying the SDPAnswer.

c) Message 5-Message 6: The call agent P-CSCF1 receives the SIP message carrying the SDP Answer, completes the offer/reply Offer/Answer matching, uses the PUSH mode to reserve QoS resources for UA1 according to the matching result, and after the resource reservation is completed , forwarding the SIP message carrying the SDP Answer to the UA1 terminal, and carrying the reservation result (QoSresult indication) of QoS resource reservation for the terminal UA1 in the SIP message.

d) Message 7-Message 8: The terminal UA1 sends a SIP message to the terminal UA2 to reach the call agent P-CSCF2;

e) Message 9: The call agent P-CSCF2 sends a SIP message to the terminal UA2, and carries an instruction in the SIP message according to the saved reservation result of QOS resource reservation for the terminal UA2, and instructs UA2 to perform QoS for it Reservation result of resource reservation (QoS indication).

As shown in Figure 5, the specific control process of the present invention is illustrated as follows with a specific example:

Message 1-Message 3: The calling terminal Caller sends a call request INVITE, which carries SDPOffer;

Message 4: The called terminal Callee responds with a 183 response and carries the SDP Answer to the called side call proxy P-CSCF.

Message 5: The call agent P-CSCF on the called side completes the Offer/Answer matching, and reserves QoS resources through the Service-based Policy Decision Function (SPDF: Service-based Policy Decision Function). If the QoS resource reservation fails, the called side The call proxy P-CSCF saves the reservation result, and forwards the 183 response.

Message 6: The call agent P-CSCF on the calling side receives a 183 response, completes the SDP Offer/Answer matching, fails to interact and reserve QoS resources through the service-based policy decision function SPDF, and further carries the calling side QoS resources in the 183 response The reservation result is delivered to the calling terminal Caller (for example, through the P-Media-Authorization header field), and the calling terminal Caller receives a 183 response, and learns that the calling side QoS resource reservation fails according to the P-Media-Authorization.

Message 7-Message 12: Through the provisional response acknowledgment message (PRACK: Provisional ResponseACKnowledgement), the called side P-CSCF2 carries the QOS resource reservation result of the called side to the called terminal Callee through the P-Media-Authorization header field. The called terminal Callee receives the PRACK, and according to the P-Media-Authorization in it, learns that the QoS resource reservation on the local side fails.

In addition to the aforementioned method, the P-CSCF notifies the terminal on the local side of the reservation result of the QOS resource, and the P-CSCF can also send the reservation result of the QOS resource on the local side to the other side of the call through a SIP message.

As shown in Figure 6, in this example, the call agent P-CSCF on the called side completes Offer/Answer matching, and performs QoS resource reservation through Service-based Policy Decision Function (SPDF: Service-based Policy Decision Function). If the reservation fails, the call proxy P-CSCF on the called side adds the relevant SIP header field in the 183 response to indicate that the P-CSCF on the called side fails to reserve QoS resources, and passes this indication information to the call proxy P-CSCF on the calling side .

After the calling agent P-CSCF reserves the QOS resources for the calling terminal, it adds a QOS resource reservation result indication on its own side, and continues forwarding the 183 response. Therefore, when the calling terminal receives the 183 response, it can know the QOS resource reservation status of the local end and the remote end respectively.

Furthermore, the QOS resource reservation results of the calling terminal and the called side can also be transmitted to the called terminal through the subsequent request message PRACK from the calling terminal to the called terminal, so that the called terminal can also know the QOS of the local end and the remote end. Resource reservations.

According to the RFC3312 (Integration of Resource Management and Session Initiation Protocol) protocol, the calling terminal can request PreCondition when initiating a session, that is, the called terminal starts ringing only after the calling and called side QoS resource reservations are successful, and the calling terminal The terminal listens to the ringback tone.

As shown in Figure 7, the PreCondition process in PULL mode (only shows the process between terminals, omitting network equipment), the calling terminal Caller and the called terminal Callee complete SDP Offer and SDP through message (1)-message (4) Answer match, and respectively adopt PULL mode to start resource reservation. When the calling side QoS resources are reserved successfully, the calling terminal Caller sends an UPDATE message to the called terminal Callee to notify the called terminal Callee that the calling side QoS resources have been successfully reserved; if the called side QoS resources are also reserved at this time If successful, the called terminal Callee rings and sends a 180 response to the calling terminal Caller, and the calling terminal Caller user listens to the ringback tone.

In the PUSH mode, usually the terminal cannot directly know the result of resource reservation. Using the aforementioned method of the present invention, after the calling terminal Caller knows the result of QoS resource reservation, when the resource reservation is successful, an UPDATE notification can be sent according to the requirements of the PreCondition process. The calling side QoS resources of one terminal (the called terminal Callee) have been successfully reserved, so that the PreCondition process can proceed normally.

For this call flow using the premise extension PreCondition, the terminal does not know when to send an UPDATE to the opposite end to notify the message that the local end has successfully reserved QOS resources. The existing PUSH mode cannot realize the PreCondition call flow, but in the present invention In the process, the Call Agent on the calling side and the Calling Agent on the called side complete the Offer/Answer matching, interact with the transport layer, reserve QoS resources, carry the QoS resource reservation results of the calling side and the called side in the response, and pass it to the calling party For the terminal, when the QoS resources on the calling side are reserved successfully, the calling terminal sends an UPDATE message to the called terminal to implement the PreCondition call process.

In the present invention, the calling terminal or the called terminal can perform the following operations based on the received "QoS resource reservation result indication":

If the calling terminal or called terminal is an intelligent terminal, it will be presented to the user in a readable manner; if the calling terminal or called terminal is an IAD terminal, it will notify the user with a specified prompt tone.

The method of the present invention is based on the received "QoS resource reservation result indication", and the user terminal can perform the following operations:

The received "QoS resource reservation result indication" is notified to the user at the user terminal. For example, if it is a smart terminal, it is presented to the user in a user-readable manner, and if it is an IAD terminal, it is notified to the user with a specific prompt tone. In the case of not using QOS PreCondition, when the QoS resources on one side are not reserved successfully, the user can still choose to terminate the call from the signaling level, or try to use the best-effort QoS service to continue the call. However, in the PUSH mode of the prior art, when the call agent fails to reserve QoS resources, the call is released directly. Obviously, the present invention provides a more flexible choice for the user.

In this way, in the present invention, the terminal knows whether the QoS resource reservation is successful, and the user can make more flexible choices based on this information. For example, when the calling terminal or the called terminal is an intelligent terminal, user-readable If the calling terminal or called terminal is an IAD terminal, the specified prompt tone can be used to notify the user; if the QoS resources on the calling or called side are not reserved successfully, the user can terminate the call from the signaling level , or try to maintain QoS service to continue the call.

In summary, the present invention enhances and perfects the call flow of QoS resource reservation in PUSH mode by transmitting the QoS resource reservation result to the terminal, and has strong practicability.

Although the above has described the present invention in conjunction with specific embodiments, obviously, based on the above inspiration, those skilled in the art can implement various replacement or improvement methods without any creative effort, and details will not be repeated here.

Claims (9)

1. A call method using PUSH mode, characterized in that: during the call process, it includes reserving QoS resources and transmitting the QoS resource reservation result to the terminal, and the QoS resource reservation result is extended through the SIP protocol Head field carrying; including the following steps: A. The calling terminal sends a message, and the call agent sends the message to the called terminal, which carries the provision information SDP Offer of the session description protocol; B. The called terminal responds with a message to the call agent, which carries the reply information SDP Answer of the session description protocol; C. The call agent completes the matching of Offer and Answer, reserves QoS resources according to the matching result, carries the QoS resource reservation result in the message, and transmits it to the calling or called terminal. 2. The call method using PUSH mode according to claim 1, characterized in that: said step A comprises the following steps: The calling terminal sends a message, and the call agent on the calling side forwards the message to the call agent on the called side, and the call agent on the called side sends the message to the called terminal, which carries the provision information SDP Offer of the session description protocol; Said step B comprises the following steps: The called terminal responds with a message to the called side call agent, which carries the reply information SDP Answer of the session description protocol; the called side call agent forwards the message to the calling side call agent. 3. The calling method adopting PUSH mode according to claim 2, characterized in that: Described step C comprises the following steps; C1. The call agent on the called side completes the matching of Offer and Answer, interacts with the transport layer, reserves QoS resources, carries the QoS resource reservation result on the called side in the response, and transmits it to the call agent on the calling side; C2. The call agent on the calling side receives the response, completes the matching of Offer and Answer, interacts with the transport layer, reserves QoS resources, and further carries the QoS resource reservation result on the calling side in the response and transmits it to the calling terminal . 4. The call method using PUSH mode according to claim 3, characterized in that: after the step C2, the following steps are also included: C3. When the QoS resources on the calling side are reserved successfully, the calling terminal sends an UPDATE message to the called terminal. 5. The call method using PUSH mode according to claim 4, characterized in that: after the step C3, the following step C4 is also included: C4. If the QoS resources on the called side are also reserved successfully, the called terminal rings and sends a 180 response to the calling terminal. 6. The calling method adopting PUSH mode according to claim 2, characterized in that: Described step C comprises the steps: C1) The call agent on the called side completes the matching of Offer and Answer, interacts with the transport layer, reserves QoS resources, carries the QoS resource reservation result of the called side in the response and transmits it to the calling terminal; C2) Carrying the "QOS resource reservation indication" in the subsequent SIP message sent by the calling terminal to the called terminal, sending the reservation result of the called side to the called terminal. 7. The calling method adopting PUSH mode according to claim 2, characterized in that: Described step C comprises the following steps; c1) The call agent on the called side completes the matching of Offer and Answer, interacts with the transport layer, and reserves QoS resources; c2) When a SIP message is subsequently sent from the calling terminal to the called terminal, the call agent on the called side carries the QoS resource reservation result on the called side in the SIP message and sends it to the called terminal. 8. The call method using PUSH mode according to any one of claims 2-7, characterized in that: when the calling terminal and called terminal are intelligent terminals, the QoS resource reservation result is based on user presented to the user in a readable manner; or, When the calling terminal and the called terminal are IAD terminals, the QoS resource reservation result is notified to the user with a designated prompt tone. 9. The call method using PUSH mode according to any one of claims 2-7, characterized in that: the QoS resource reservation result is extended by using the P-Media-Authorization header field.

Images