WO2011023041A1 - 一种指示终端媒体类型的呼叫方法及*** - Google Patents

一种指示终端媒体类型的呼叫方法及*** Download PDF

Info

Publication number
WO2011023041A1
WO2011023041A1 PCT/CN2010/075291 CN2010075291W WO2011023041A1 WO 2011023041 A1 WO2011023041 A1 WO 2011023041A1 CN 2010075291 W CN2010075291 W CN 2010075291W WO 2011023041 A1 WO2011023041 A1 WO 2011023041A1
Authority
WO
WIPO (PCT)
Prior art keywords
user terminal
media
application server
request message
call
Prior art date
Application number
PCT/CN2010/075291
Other languages
English (en)
French (fr)
Inventor
王立波
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2011023041A1 publication Critical patent/WO2011023041A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • the present invention relates to the field of communications, and in particular, to a nested scenario of an IMS domain service, and proposes a new type of media. Background technique
  • IP Multimedia Core Network Subsystem is an IP-based network architecture proposed by the 3rd Generation Partnership Project (3GPP). It is an open and flexible platform. The business environment supports multimedia applications and provides users with rich multimedia services.
  • IMS is an IP-based telecommunications network architecture that is independent of access technology, except for GPRS (General Packet Radio Service), WLAN (Wireless Local)
  • GPRS General Packet Radio Service
  • WLAN Wireless Local
  • WLAN can provide services for mobile cellular networks such as GSM (Global System for Mobile communications) and UMTS (Universal Mobile Telecommunications System). .
  • GSM Global System for Mobile communications
  • UMTS Universal Mobile Telecommunications System
  • the IMS domain calls use the SIP (Session Initial Protocol) protocol, and the SIP protocol requires that the media negotiation must satisfy the OFFER/ANSWER model (see rfc3264). That is, the OFFER/ANSWER must appear in pairs, and there are no consecutive 2 The same type of OFFER (this case specifies that the second OFFER is rejected with a 491 message), and an ANSWER without an OFFER cannot occur.
  • SIP Session Initial Protocol
  • the call request INVITE is received, resource preparation work for the call is required. If the initial session request INVITE received by the called party does not carry media, the terminal as the called party cannot know what kind of media should be prepared, especially if the called terminal capability is stronger than the calling terminal capability. The ability to call the actual support of the caller is more troublesome for the called party. What is more, if the ability between the calling terminal and the called terminal does not intersect, the subsequent media negotiation cannot be completed.
  • IMS system framework defined by TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) is shown in Figure 1.
  • TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking
  • UE User terminal, User Equipment.
  • CSCF Call Session Control Function
  • IMS Internet Multimedia Subsystem
  • CSCF is further divided into three categories: P-CSCF, S-CSCF, and I-CSCF.
  • P-CSCF Proxy CSCF
  • P is the node that the user accesses the core network and is closest to the user in the CSCF of the IMS.
  • the UE's message is forwarded and the SIP message received from the outside is returned to the UE.
  • P can be seen as a proxy in SIP.
  • S-CSCF (Serving CSCF): S is the core of the core in IMS. It is in the core control position of IMS. Basically, any SIP message must be processed through it, including routing, AS service triggering, and redirection. S can be seen as Registrar, Proxy and Redirect Server in SIP.
  • I-CSCF Interrogating-CSCF: I is a border node of a network, which mainly locates the called S in an incoming call, thereby hiding the topology of the network, because if all incoming calls pass through the network I, the outside user has no way of knowing the distribution of network elements such as S and P inside the network. I is optional, which means that if you don't want to hide your network structure, you don't need such a network element. Because the incoming call goes through I, although the function of I is relatively simple, but the burden is relatively heavy, so once a network uses I, there is usually more than one, in order to load balance. Because of this, I don't care about the state of the conversation.
  • I can do other work with I, such as filtering incoming requests, counting call data, and so on.
  • I usually also accept REGISTER requests within your network and assign an S to them.
  • I can be seen as a Proxy ⁇ Redirect Server in SIP.
  • HSS Home Subscriber Server
  • I authentication information
  • S User Data
  • AS Application Server
  • Step 201 UE-A initiates an initial session request INVITE The message arrives at the AS and carries the SDP of the user A.
  • Step 202 The AS forwards the INVITE to the UE-B.
  • Steps 203-204 The UE-B returns 183 and carries the SDP of the user B.
  • Step-205-206 UE-A back PRACK message to UE-B; Steps 207-208: UE-B returns PRACK message to UE-A; Step-209: 210: UE-B returns 180 message to UE-A; User B is in ringing.
  • the AS waits for the response timer to time out, cancels the call to B, and then re-initiates the call to C.
  • the following is the specific procedure.
  • Steps 211-214 The AS cancels the call to the UE-B.
  • Step 215 The AS initiates a call to the UE-C, and does not carry the SDP.
  • Step 216 The UE-C returns 183, and carries the SDP of the UE-C.
  • Step 217 The AS transmits the SDP of the UE-C to the UE-A through the UPDATE; Step 218: The UE-A returns 200, and carries the media of the UE-A; Step 219: The AS sends the SDP of the UE-A to the UE-C through the PRACK; 220: UE-C returns 200 (PRACK); Steps 221-222: UE-C rings, returns 180; User c is in a ringing state. Steps 223-224: UE-C picks up the call and sends 200 OK to UE-A; Steps 225-226: UE-A returns UE-C ACK message;
  • FIG. 3 is a schematic flowchart of a process of implementing a user auto-station and an INVITE without an SDP according to the related art. The steps are as follows: Step 301: The UE-A initiates an initial session request INVITE message to the AS, and carries the SDP of the user A. Step 302 : AS returns 200 OK, carries the prompt tone medium; Step 303: UE-A returns ACK, and UE-A establishes a call with the AS;
  • Step 304 The AS initiates a call to UE-B, and the number of the UE-B is obtained by the AS number received in the previous step; Step-by-step 305: UE-B back to 183, carrying the UE- SDP of B: Step 306: The AS sends the media to the UE-A through the re-INVITE; Step-by-step 307: The UE-A returns 200 OK, and carries the SDP of the UE-A.
  • the AS waits for the UE-B response timer to expire, then cancels the call to UE-B and re-acquires the number.
  • Steps 312-315 The AS releases the call to the UE-B;
  • Step 322 AS back ACK;
  • Step 324 The called party picks up the phone and returns 200 OK.
  • Step 325 The AS returns an ACK to the UE-C.
  • Steps 327-329 The call is released.
  • Steps 303-304 The UE-B returns 183 response, carrying the SDP of the user B.
  • Steps 305-306 The UE-A returns a PRACK message to the UE-B.
  • Steps 307-308 The UE-B returns a PRACK message to UE-A;
  • Step-Shop 309-310 UE-B returns 180 message to UE-A; User B is in ringing.
  • Steps 311-314 The AS cancels the call to UE-B; Step 315: The AS initiates a call to the UE-C, does not carry the SDP; Steps 316-317: UE-C returns 183, carries the SDP of the UE-C; 318-319: UE-A returns UE-C PRACK, carries the media of UE-A; Steps 320-321: UE-C returns UE-A 200 OK; Steps 322-323: UE-C rings, returns 180; User C It is in a ringing state. Step 324: UE-C picks up the phone and sends a 200 OK to UE-A. Step 325: UE-A returns a UE-C ACK message.
  • Step 401 The UE-A initiates an initial session request INVITE message to the AS, and carries the SDP of the user A.
  • Step 402 The AS forwards the INVITE to the UE-B.
  • Steps 403-404 The UE-B returns 183 and carries the SDP of the user B.
  • Steps 405-406 The UE-A returns a PRACK message to the UE-B.
  • 407-408 UE-B returns PRACK message to UE-A;
  • Step-S) 409-410 UE-B returns 180 message to UE-A; User B is in ringing.
  • the AS waits for the response timer to time out, cancels the call to B, and then re-initiates the call to C.
  • the following is the specific procedure.
  • Steps 411-414 The AS cancels the call to the UE-B.
  • Step 415 The AS initiates a call to the UE-C, and carries the SDP.
  • the SDP may be the media carried in the INVITE of the UE-A, or carried in a certain step.
  • Step 416 UE-C back 183, carrying the SDP of the UE-C
  • Step 417 The AS sends the SDP of the UE-C to the UE-A through the UPDATE
  • Step 418 UE-A Returning to 200, carrying the media of the UE-A
  • Step 419 The AS sends a PRACK to the UE-C; whether the media of the UE-A carried in the step 418 is transferred to the UE-C, and the decision is made by the AS, if the decision needs to be transferred Then, the UE-C can be sent by using the PRACK or the UPDATE.
  • Step 420 UE-C returns 200 OK.
  • Steps 421-422 UE-C rings, returns 180; User C is in the ringing state.
  • Steps 423-424 UE-C picks up the call and sends 200 OK to UE-A.
  • Steps 425-426 UE-A returns UE-C ACK message;
  • Steps 427-430 The UE-C hangs up and the call ends.
  • 5 is a schematic flowchart of a process of implementing an automatic station flow and an INVITE carrying an SDP according to the related art. The steps are as follows: Step 501: The UE-A initiates an initial session request INVITE message to the AS, and carries the SDP of the user A. Step 502: The AS returns 200 OK and carries the prompt tone medium. Step 503: The UE-A returns an ACK, and the UE-A establishes a call with the AS.
  • Step 504 The AS initiates a call to UE-B, and the number of the UE-B is obtained by the AS number of the previous step;
  • Step 505 UE-B returns 183, carries the UE-B SDP:
  • Step 506 The AS sends the media to the UE-A through the re-INVITE.
  • Step 507 The UE-A returns 200 OK and carries the SDP of the UE-A.
  • B Step 509: UE-B returns 200 OK (PRACK);
  • Step 511 UE-B returns 180 message;
  • the AS waits for the UE-B response timer to time out, cancels the call to UE-B, re-receives the number, and initiates a call to the new recipient.
  • Steps 512-515 The AS releases the call attempt to the UE-B.
  • Step 516 The AS initiates the INVITE, and the UE-C carries the SDP.
  • the SDP may be the media carried in the INVITE of the UE-A, or in a certain step.
  • Step 517 UE-C back 183, carrying the SDP
  • Step 518 The AS sends the SDP of the UE-C to the UE-A through the re-INVITE
  • Step-Step 519 UE- A back 200, carrying the SDP of the UE-A; whether the media of the UE-A carried in the step 519 is transferred to the UE-C, and the decision is made by the AS through the decision, if the decision needs to be transferred, then the PRACK or the UPDATE may be sent again.
  • Step 519 the media carried in step 519 need not be transferred to UE-C;
  • Step 524 The called party picks up the phone and returns to 200 OK.
  • Step 525 The AS returns an ACK to the UE-C.
  • Steps 526-529 The call is released.
  • the above four pictures respectively show that the non-response forwarding INVITE does not carry the SDP, the automatic station INVITE does not carry the SDP, the non-response forward INVITE carries the SDP, and the automatic station INVITE carries the SDP implementation process, and the negotiation process is through reliable transmission. Carrying the media, and then sending the 180 way, the flow chart can also be changed by means of reliable transmission of 180 portable media; the above four pictures are introduced using a non-precondition process, the precondition process only adds notification of media reservation completion, the principle Similar, no longer said.
  • the AS only sends the answer media that is called back to the offer media (so the offer/answer model between the caller and the AS is already paired;), so the answer to offer appears. Answer to offer will increase the chance of media negotiation conflicts, and may also cause media shocks.
  • the present invention provides a new SDP, which is used to indicate the called party: the calling media, and the SDP does not belong to the scope of the session media of er ⁇ answer negotiation, which solves the problem that the called party prepares the media on the side.
  • SDP Session Description Protocol
  • the present invention provides a calling method for indicating a terminal media type, including the following steps: a first user terminal calls a second user terminal by using a server; if the second user terminal does not respond, the application server sends a third user terminal to the third user terminal. Sending a request message, the request message carries the media about the first user terminal; the third user terminal initiates a negotiation with the first user terminal based on the media about the first user terminal in the request message; the first user terminal and the first After the negotiation of the three user terminals is completed, the call is made.
  • the method specifically includes the following steps: the first user terminal uses the server to apply to the second user.
  • the terminal sends a request message for calling the second user terminal.
  • the second user terminal negotiates with the first user terminal.
  • the application server waits for the response timer to expire, and cancels the second user terminal. call.
  • the method specifically includes the following steps: the first user terminal sends the call to the application server for calling a request message of the application server; the application server negotiates with the first user terminal after receiving the request message, and talks with the first user terminal after the negotiation is completed; the first user terminal initiates a call to the second user terminal through the application server; After the user terminal receives the call, A user terminal negotiates; after the negotiation is completed, the application server waits for the response timer to expire, and cancels the call to the second user terminal.
  • the method further includes: if the second user terminal has a response, the second user terminal performs a call with the first user terminal.
  • the step of the first user terminal calling the second user terminal by using the application server includes the following steps: The first user terminal sends the application server to the application server for calling the application server.
  • the application server negotiates with the first user terminal after receiving the request message, and talks with the first user terminal after the negotiation is completed;
  • the first user terminal sends a request message to the second user terminal through the application server, and the request message carries Regarding the media of the first user terminal;
  • the second user terminal initiates a negotiation with the first user terminal based on the media about the first user terminal in the request message; after the negotiation is completed, the application server waits for the second user terminal to respond.
  • the third user terminal or the second user terminal based on the media initiating the first user terminal in the request message, and the first user terminal, includes: the third user terminal or the second user terminal according to the request message.
  • the media of the first user terminal initiates an offer to the application server; the application server forwards the offer initiated by the third user terminal or the second user terminal to the first user terminal; the first user terminal uses the server to apply the server
  • the third user terminal or the second user terminal returns a response answer, wherein the media in the request message has a first type identifier, and the media with the first type identifier and the second type identifier defined in the session initiation protocol SIP
  • the first type identifier is Content-Disposition: notice-session, where the media about the first user terminal carried in the request message is the media of the first user terminal or the application server ⁇ ' ⁇ The changed media of the first user terminal.
  • the invention also proposes a call indicating the type of the terminal media.
  • the system includes: a first user terminal, a second user terminal, a third user terminal, and an application server, wherein the first user terminal is configured to call the second user terminal by using the application server;
  • the request message is sent to the third user terminal, where the request message carries the media with the first type identifier about the first user terminal, and the third user terminal is configured to be based on the request message.
  • Negotiating the media between the first user terminal and the first user terminal, and making a call with the first user terminal after the negotiation is completed.
  • the media in the request message has a first type identifier, and the media having the first type identifier is different from the media having the second type identifier defined in the session initiation protocol SIP.
  • the first type identifier is Content-Disposition: notice-session.
  • the media about the first user terminal carried in the request message is the media of the first user terminal or the media of the first user terminal that has been tampered with by the application server.
  • FIG. 1 is a schematic diagram of an IMS system reference frame according to the related art
  • FIG. 2 is a schematic diagram of a IMS domain implementing a user's no-answer forward according to the related art and a new call INVITE not carrying an SDP
  • FIG. The IMS domain of the technology implements the automatic station and the new call INVITE does not carry the schematic diagram of the new type SDP
  • FIG. 1 is a schematic diagram of an IMS system reference frame according to the related art
  • FIG. 2 is a schematic diagram of a IMS domain implementing a user's no-answer forward according to the related art and a new call INVITE not carrying an SDP
  • FIG. The IMS domain of the technology implements the automatic station and the new call INVITE does not carry the schematic diagram of the new type SDP
  • FIG. 1 is a schematic diagram of an IMS system reference frame according to the related art
  • FIG. 2 is a schematic diagram of a IMS domain implementing a user's no-answer forward
  • FIG. 4 is a schematic diagram of the process of implementing the user's no answer forwarding and the new call INVITE carrying the session SDP according to the related art IMS domain;
  • FIG. 6 is a schematic flowchart of implementing an IMS domain to implement a user no answer forwarding and a new call INVITE carrying a new type SDP according to an embodiment of the present invention;
  • FIG. 7 is a schematic diagram of a process in which an IMS domain implements an automatic station according to an embodiment of the present invention and a new call INVITE carries a new type of SDP;
  • FIG. 8 is a schematic diagram of a system implemented by the present invention.
  • the present invention provides a new type of SDP, which distinguishes it from a session SDP that performs media negotiation by a certain identifier.
  • the new type of SDP is identified by defining Content-Disposition: notice-session.
  • the application scenario of the new type of SDP is as follows: When the initial INVITE carries the SDP, but the AS (service server) initiates a new call, it is found that the media carried by the initial INVITE has been negotiated, and the SDP is carried in the INVITE. Going to a new user will result in a answer to offer.
  • the SDP ⁇ _ is a new type of SDP, and then the new type of SDP is carried by the INVITE to the new user, so that the media that is called back is an offer medium, and thus not? I starts the operation of answer to offer.
  • the non-response forwarding and automatic station are still taken as an example to introduce the signaling diagram after using the new type of SDP.
  • the figure still carries the media with reliable transmission of 183, and still uses the process that does not support precondition (resource reservation) as an example. However, the process of using precondition, the process of using reliable 180 to carry media, or the process of updating and switching media does not differ from the schematic process, so it is not exhaustive.
  • Step 601 UE-A (ie, the first user terminal) initiates an initial session request.
  • the INVITE message is sent to the AS and carries the SDP of the user A.
  • Step 602 The AS forwards the INVITE to the UE-B (ie, the second user terminal;);
  • Steps 603-604 The UE-B returns 183 and carries the SDP of the user B.
  • Steps 605-606 UE-A returns PRACK message to UE-B;
  • Step-S607-608 UE-B returns 200 (PRACK) message to UE-A;
  • Step-Shop 609-610 UE-B back 180 message Give UE-A; User B is ringing.
  • Steps 611-614 The AS cancels the call to UE-B; Step 615: The AS initiates a call to the UE-C (ie, the third user terminal), carrying a new type of SDP (ie, having the first with respect to the first user terminal) The media of the type identifier is determined by the type identifier (referred to as the first type identifier).
  • the SDP is not used as the session SDP (that is, the media with the second type identifier defined in the SIP), and does not participate in the negotiation process of offer/answer;
  • the user uses Content-Disposition: notice-session as the identifier of the new media;
  • Step 616 UE-C returns 183, carries the SDP of the UE-C, and acts as the SDP of the offer;
  • Step 617 The AS sends the SDP of the UE-C through the UPDATE.
  • Step 618 UE-A returns 200, carries the SDP of the UE-A;
  • Step 619 The AS sends a PRACK to the UE-C, and carries the SDP of the UE-A as the SDP of the answer;
  • Step 620 UE-C Go back to 200 OK;
  • Steps 621-622 UE-C rings, returns 180;
  • User C is in the ringing state.
  • Steps 625-626 UE-A returns UE-C ACK message;
  • FIG. 7 is a schematic flowchart of an IMS domain implementing an automatic station flow and an INVITE carrying an SDP according to an embodiment of the present invention. The steps are as follows: Step 701: The UE-A initiates an initial session request INVITE message to the AS, and carries the SDP of the user A. ; Step 702: The AS returns 200 OK and carries the prompt tone medium. Step 703: UE-A returns an ACK, and a call is established between the UE-A and the AS.
  • Step 704 The AS initiates a call to UE-B, and the number of the UE-B is obtained by the AS number received in the previous step;
  • Step-Step 705 UE-B returns 183, carries the UE- SDP of B:
  • Step 706 The AS sends the media to the UE-A through the re-INVITE;
  • Step-S97 UE-A returns 200 OK, carries the SDP of the UE-A;
  • Step 710 AS returns UE-A ACK message;
  • Step 711 UE-B returns 180 message;
  • the AS waits for the UE-B response timer to time out, cancels the call to UE-B, re-receives the number, and initiates a call to the new recipient.
  • Steps 712-715 The AS releases the call to the UE-B.
  • Step 716 The AS initiates the INVITE, and the UE-C carries the new type of SDP.
  • the SDP is determined not to be the session SDP by the type identifier, and does not participate in the offer/ The answer negotiation process; in the figure, use Content-Disposition: notice-session as the standard K of the new media; Step 717: UE-C back 183, carrying the SDP as the offer; Step 718: The AS passes the SDP of the UE-C through re - INVITE is sent to UE-A; Step 719: UE-A returns 200, carries the SDP of UE-A; Step 720: The AS sends the media SDP to the UE-C through a PRACK message, and the SDP acts as Step 721: UE-C returns 200 OK; Step 722: AS returns ACK; Step 723: UE-C returns 180; UE-C is in ringing.
  • Step 724 The called party picks up the phone and returns to 200 OK.
  • Step 725 The AS returns an ACK to the UE-C.
  • the A and C users enter the call.
  • the media carried by the call request sent to the UE-C may be the UE-A media, or may be the modified media of the AS based on the UE-A media, such as modifying the IP, PORT, and the like.
  • the above embodiment has other transformations, for example: The new type of SDP passes other identifiers instead of Content-Disposition: notice-session. Obviously, in the embodiment shown in FIG.
  • step S729 occurs.
  • the called party in this case, UE-B
  • the AS initiates an INVITE to the UE-B, and carries a new type of SDP.
  • the type identifier is used to determine that the SDP is not a session SDP and does not participate in the offer/answer.
  • the ten-business process; in the figure, Content-Disposition: notice-session is used as the identifier of the new media, and the above problems existing in this embodiment can be solved.
  • the step S704 is the same as the above step S716, and the subsequent steps S705 to S708 are the same as the above steps S717 to S720.
  • the present invention also provides a SIP-based call system indicating a terminal media type. Referring to FIG.
  • the present invention includes: a first user terminal, a second user terminal, a third user terminal, and an application server, a first user terminal, configured to call the second user terminal by using the application server, and configured to send, by the application server, a request message to the third user terminal, where the request message carries the first user And a third user terminal, configured to initiate a negotiation with the first user terminal based on the media about the first user terminal in the request message, and after the negotiation is completed, the first user terminal Make a call.
  • the medium in the request message has a first type identifier (for example, Content-Disposition: notice-session), and the medium having the first type identifier and the second type identifier (ie, session SDP) defined in the session initiation protocol SIP.
  • the media is different.
  • the media about the first user terminal carried in the request message is the media of the first user terminal or the media of the first user terminal that has been tampered with by the application server.
  • a general-purpose computing device which can be centralized on a single computing device or distributed over a network of multiple computing devices.
  • they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device, or they may be fabricated into individual integrated circuit modules, or multiple of them Modules or steps are made in a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Description

一种指示终端媒体类型的呼叫方法及*** 技术领域 本发明涉及通信领域， 尤其涉及 IMS域业务嵌套场景， 提出一种新类型 的媒体。 背景技术
IP多媒体子*** （ IP Multimedia Core Network Subsystem, 简称 IMS ) 是由第三代合作伙伴计划 （ 3rd Generation Partnership Project, 简称 3GPP ) 组织提出的一种基于 IP的网络架构， 其构建了一个开放而灵活的业务环境， 支持多媒体应用， 并为用户提供丰富的多媒体业务。
IMS 是基于 IP 的电信网络架构， 与接入技术无关， 除了可以为 GPRS ( General Packet Radio Service, 通用分组无线业务 ), WLAN ( Wireless Local
Area Network, 无线局域网） 等分组接入网络提供业务外， 还可以为 GSM ( Global System for Mobile communications, 全球移动通讯***）、 UMTS ( Universal Mobile Telecommunications System, 统一移动通讯*** ) 等移动 蜂窝网络提供业务。
IMS域呼叫釆用 SIP ( Session Initial Protocol, 会话初始协议 )协议， 而 SIP协议要求媒体的协商必须满足 OFFER/ANSWER模型 （详见 rfc3264 ), 即 OFFER/ANSWER必须成对出现， 不能出现连续 2个同类型的 OFFER (这 种情况协议规定用 491 消息拒绝第二个 OFFER ), 不能出现没有 OFFER的 ANSWER。 作为被叫的终端侧， 接收到呼叫请求 INVITE, 需要进行用于通话的资 源准备工作。 如果被叫接收到的初始会话请求 INVITE中没有携带媒体， 则 作为被叫的终端， 则无法知道应该准备什么样的媒体， 特别在被叫终端能力 比主叫终端能力强的情况下， 由于被叫不知道主叫实际支持的能力， 对被叫 造成的困扰更大， 更有甚者， 如果主叫终端与被叫终端之间能力没有交集的 话， 则后续媒体的协商无法完成。
TISPAN ( Telecommunications and Internet converged Services and Protocols for Advanced Networking ) 定义的 IMS***框架见图 1 , 部分网元 功能如下：
UE: 用户终端， User Equipment。
CSCF( Call Session Control Function,呼叫会话控制功能）： CSCF是 IMS 中的会话控制功能体。 CSCF在 IMS中实现了多媒体呼叫中主要的软交换控 制功能， 可以看作 SIP中的各种基本 Server的集合。
CSCF又分为三类： P-CSCF、 S-CSCF、 I-CSCF。
P-CSCF ( Proxy CSCF ): P是用户接入核心网的节点， 在 IMS的 CSCF 中离用户最近。对外转发 UE的消息并且将从外面收到的 SIP消息返回给 UE。 P可以看作 SIP中的 Proxy。
S-CSCF ( Serving CSCF ) ： S是 IMS中核心中的核心， 处于 IMS的核心 控制地位，基本上任何 SIP消息都要经过它的处理， 包括路由、 AS业务触发、 重定向等主要控制功能。 S可以看作 SIP中的 Registrar, Proxy以及 Redirect Server„
I-CSCF ( Interrogating-CSCF ): I是一个网络的边界节点， 主要对外来呼 叫中的被叫的 S进行定位， 从而隐藏该网络的拓朴结构， 因为若所有外来呼 叫啫卩要经过该网络的 I , 则外面的用户无从知道该网络内部 S以及 P等网元 的分布情况。 I 是可选的， 也就是说如果不想刻意隐藏自己的网络结构， 则 可以不需要这样一个网元。 因为进入的呼叫都要经过 I, 虽然 I的功能较为单 一， 但负担比较重， 因此一个网络一旦使用了 I, 一般就不止一个， 以便进 行负载均衡。 也正因为如此， I是不会关心会话状态的。 当然， 因为 I的特殊 位置， 也可以借助 I做些其他工作， 比如过滤外来请求， 统计呼叫数据等。 I 通常还接受自己网络内的 REGISTER请求， 并为其指定一个 S。 I可以看作 SIP中的 Proxy ^ Redirect Server。
HSS ( Home Subscriber Server, 归属签约用户服务器）： 是用于集中存放 用户数据 （认证信息、 业务信息、 漫游信息、 原始计费信息等） 的地方， 用 户数据总是存放在其归属域 （开户地） 的 HSS 中， 可以跟 HSS直接通信的 有 I, S和 AS等， UE不会跟 HSS有直接接触。 一个网络可以配置多个 HSS , 这时就需要 SLF ( Subscriber Location Function, 签约用户位置功能） 将一个 用户地址映射到对应 HSS。 这时 SLF就是 SIP中的一个 Redirect Server。 AS ( Application Server, 应用服务器）： 用于实现具体业务的服务器。 通 常 AS由 S根据用户请求以及触发条件进行触发，它是作为 SIP中的 B2BUA 实现的。 IMS中的这种触发机制正是其支持业务与承载分离的基础。 图 2是根据相关技术的 IMS域实现用户无应答前转并且新呼叫 INVITE 不带 SDP ( Session Description Protocol, 会话描述协议） 的流程示意图， 步 骤说明如下： 步骤 201 : UE-A发起初始会话请求 INVITE消息到 AS , 携带用户 A的 SDP; 步骤 202: AS转发 INVITE给 UE-B; 步骤 203-204: UE-B回 183响应， 携带用户 B的 SDP; 步-骤 205-206: UE-A回 PRACK消息给 UE-B; 步-骤 207-208: UE-B回 PRACK消息给 UE-A; 步-骤 209-210: UE-B回 180消息给 UE-A; 用户 B处于振铃中。
AS等待应答定时器超时， 取消到 B的试呼， 然后重新发起到 C的试呼， 下面是具体流程。 步骤 211-214: AS取消到 UE-B的试呼； 步骤 215 : AS发起到 UE-C的呼叫， 不携带 SDP; 步骤 216: UE-C回 183 , 携带 UE-C的 SDP; 步骤 217: AS将 UE-C的 SDP通过 UPDATE带给 UE-A; 步骤 218: UE-A回 200, 携带 UE-A的媒体； 步骤 219: AS将 UE-A的 SDP通过 PRACK发送给 UE-C; 步骤 220: UE-C回 200 ( PRACK ); 步骤 221-222: UE-C振铃， 回 180; 用户 c处于振铃状态。 步骤 223-224: UE-C摘机应答， 发送 200OK给 UE-A; 步骤 225-226: UE-A回 UE-C ACK消息；
UE-A与 UE-C进入通话中。 步骤 227-230: UE-C挂机， 通话结束。 图 3是根据相关技术的 IMS域实现用户自动台流程并且 INVITE不带 SDP的流程示意图， 步骤说明如下： 步骤 301 : UE-A发起初始会话请求 INVITE消息到 AS , 携带用户 A的 SDP; 步骤 302: AS回 200OK, 携带提示音媒体； 步骤 303 : UE-A回 ACK, UE-A与 AS之间建立通话；
AS放提示音， 并且完成收号过程； 步骤 304: AS发起到 UE-B的呼叫， UE-B的号码由上一步 AS收号得 到； 步-骤 305 : UE-B回 183 , 携带 UE-B的 SDP; 步骤 306: AS将媒体通过 re-INVITE发送给 UE-A; 步-骤 307: UE-A回 200OK, 携带 UE-A的 SDP; 步骤 308: AS将 UE-A的媒体通过 PRACK发送给 UE-B; 步骤 309: UE-B回 200OK ( PRACK ); 步骤 310： AS回 UE- A ACK消息； 步骤 311： UE-B回 180消息；
UE-B进入振铃状态；
AS等待 UE-B应答定时器超时， 则取消到 UE-B的试呼， 重新收号并发 起到新收用户的呼叫。 步骤 312-315 : AS释放掉向 UE-B的试呼； 步骤 316: AS发起 INVITE, 到 UE-C; 步骤 317: UE-C回 183 , 携带 SDP; 步骤 318: AS将媒体通过 re-INVITE发送给 UE-A; 步-骤 319: UE-A回 200, 携带 UE-A的 SDP; 步骤 320: AS将媒体通过 PRACK消息发送给 UE-C; 步骤 321 : UE-C回 200OK; 步骤 322: AS回 ACK; 步骤 323 : UE-C回 180;
UE-C处于振铃中。 步骤 324: 被叫摘机， 回 200OK; 步骤 325： AS回 ACK给 UE-C;
A、 C用户进入通话中。 步骤 327-329: 呼叫释放。 步骤 303-304: UE-B回 183响应， 携带用户 B的 SDP; 步-骤 305-306: UE-A回 PRACK消息给 UE-B; 步-骤 307-308: UE-B回 PRACK消息给 UE-A; 步-骤 309-310: UE-B回 180消息给 UE-A; 用户 B处于振铃中。
AS等待应答定时器超时， 取消到 B的试呼， 然后重新发起到 C的试呼, 下面是具体流程。 步骤 311-314: AS取消到 UE-B的试呼； 步骤 315 : AS发起到 UE-C的呼叫， 不携带 SDP; 步骤 316-317: UE-C回 183 , 携带 UE-C的 SDP; 步骤 318-319: UE-A回 UE-C PRACK, 携带 UE-A的媒体； 步骤 320-321 : UE-C回 UE-A 200OK; 步骤 322-323 : UE-C振铃， 回 180; 用户 C处于振铃状态。 步骤 324: UE-C摘机应答， 发送 200OK给 UE-A; 步骤 325： UE-A回 UE-C ACK消息；
UE-A与 UE-C进入通话中。 步骤 326-329: UE-C挂机， 通话结束。 图 4是根据相关技术的 IMS域实现用户无应答前转并且新呼叫 INVITE 携带 SDP的流程示意图， 步骤说明如下： 步骤 401 : UE-A发起初始会话请求 INVITE消息到 AS , 携带用户 A的 SDP; 步骤 402: AS转发 INVITE给 UE-B; 步骤 403-404: UE-B回 183响应， 携带用户 B的 SDP; 步-骤 405-406: UE-A回 PRACK消息给 UE-B; 步-骤 407-408: UE-B回 PRACK消息给 UE-A; 步-骤 409-410: UE-B回 180消息给 UE-A; 用户 B处于振铃中。
AS等待应答定时器超时， 取消到 B的试呼， 然后重新发起到 C的试呼， 下面是具体流程。 步骤 411-414: AS取消到 UE-B的试呼； 步骤 415 : AS发起到 UE-C的呼叫， 携带 SDP (该 SDP可能是 UE-A的 INVITE中携带的媒体， 或者某一步骤中携带的媒体， 或者 AS构造的媒体）； 步骤 416: UE-C回 183 , 携带 UE-C的 SDP; 步骤 417: AS将 UE-C的 SDP通过 UPDATE发送给 UE-A; 步骤 418: UE-A回 200, 携带 UE-A的媒体； 步骤 419: AS发送 PRACK给 UE-C; 对于步骤 418中携带的 UE-A的媒体是否转给 UE-C,跟由 AS通过决策 决定， 如果决策需要转， 则可以通过 PRACK或者 UPDATE再发个 UE-C, 由于这个转换对于本场景分析没有影响， 因此^ _定步骤 418中携带的媒体不 需要转给 UE-C; 步骤 420: UE-C回 200OK; 步骤 421-422: UE-C振铃， 回 180; 用户 C处于振铃状态。 步骤 423-424: UE-C摘机应答， 发送 200OK给 UE-A; 步骤 425-426: UE-A回 UE-C ACK消息；
UE-A与 UE-C进入通话中。 步骤 427-430: UE-C挂机， 通话结束。 图 5是根据相关技术的 IMS域实现用户自动台流程并且 INVITE携带 SDP的流程示意图， 步骤说明如下： 步骤 501 : UE-A发起初始会话请求 INVITE消息到 AS , 携带用户 A的 SDP; 步骤 502: AS回 200OK, 携带提示音媒体； 步骤 503 : UE-A回 ACK, UE-A与 AS之间建立通话; AS放提示音， 并且完成收号过程; 步骤 504: AS发起到 UE-B的呼叫， UE-B的号码由上一步 AS收号得 到； 步骤 505 : UE-B回 183 , 携带 UE-B的 SDP; 步骤 506: AS将媒体通过 re-INVITE发送给 UE-A; 步骤 507: UE-A回 200OK, 携带 UE-A的 SDP; 步骤 508: AS将 UE-A的媒体通过 PRACK发送给 UE-B; 步骤 509: UE-B回 200OK ( PRACK ); 步骤 510: AS回 UE-AACK消息； 步骤 511 : UE-B回 180消息；
UE-B进入振铃状态；
AS等待 UE-B应答定时器超时， 则取消到 UE-B的试呼， 重新收号并发 起到新收用户的呼叫。 步骤 512-515 : AS释放掉向 UE-B的试呼； 步骤 516: AS发起 INVITE, 到 UE-C, 携带 SDP (该 SDP可能是 UE-A 的 INVITE中携带的媒体， 或者某一步骤中携带的媒体， 或者 AS构造的媒 体）； 步骤 517: UE-C回 183 , 携带 SDP; 步骤 518: AS将 UE-C的 SDP通过 re-INVITE发送给 UE-A; 步-骤 519: UE-A回 200, 携带 UE-A的 SDP; 对于步骤 519中携带的 UE-A的媒体是否转给 UE-C,跟由 AS通过决策 决定， 如果决策需要转， 则可以通过 PRACK或者 UPDATE再发个 UE-C, 由于这个转换对于本场景分析没有影响， 因此^ _定步骤 519中携带的媒体不 需要转给 UE-C; 步骤 520: AS将媒体通过 PRACK消息发送给 UE-C; 步骤 521 : UE-C回 200OK; 步骤 522: AS回 ACK; 步骤 523 : UE-C回 180;
UE-C处于振铃中。 步骤 524: 被叫摘机， 回 200OK; 步骤 525 : AS回 ACK给 UE-C;
A、 C用户进入通话中。 步骤 526-529: 呼叫释放。 上述 4幅图分别介绍了无应答前转 INVITE不携带 SDP，自动台 INVITE 不携带 SDP , 无应答前转 INVITE携带 SDP , 自动台 INVITE携带 SDP的实 现流程， 协商的流程都是通过可靠传输的 183携带媒体， 然后再发送 180的 方式， 流程图也可变更为通过可靠传输的 180携带媒体的方式； 上述 4幅图 使用非 precondition流程进行介绍， precondition流程只是增加了媒体预留完 成的通知， 原理类似， 不再累述。 对于各类的前转以及一号通、 顺振、 同振的业务流程， 如果被叫未回任 何携带媒体的可靠响应， 则对媒体协商没有任何影响， 如果被叫回携带媒体 的可靠响应， 则流程图与无应答前转类似， 不再累述； 对于盲转转接、 自动 台等 AS作为 B2BUA实现业务， 一侧为通话态， 一侧为非通话态的业务， 流程图与自动台类似， 不再累述。 图 2和图 3所示的无应答前转和自动台 INVITE不带 SDP的流程， 釆用 这种流程， 会有如下问题： 被叫接收到不携带媒体的 INVITE, 则不知道应该如何准备本侧的媒体， 比如， 如果被叫支持音频和视频呼叫， 则应该准备音频的媒体， 还是视频的 媒体， 还是同时准备； 被叫无法决策釆用何种类型的媒体与主叫进行协商； 若新的媒体类型由被叫引入， 则引起计费的问题。 图 4和图 5所示为无应答和自动台 INVITE携带 SDP的流程， 釆用这种 流程， 主要的问题是： 由于第二次 INVITE中携带 offer媒体， 则被叫回的媒体是 answer的媒 体， AS只有将被叫回的 answer媒体转为 offer媒体发送出去 （因此主叫与 AS之间 offer/answer模型已经是配对的；)， 这样就出现 answer转 offer。 而 answer转 offer则会增加媒体协商冲突的几率， 同时也可能会引起媒体震荡。
( offer/answer的具体定义见 rfc3264: An Offer/Answer Model with the Session Description Protocol ( SDP ) )。 发明内容 本发明提出一种新的 SDP, 该 SDP的作用是指示被叫： 主叫的媒体， 并 且该 SDP不属于会话媒体 of er\answer协商的范畴， 既解决了被叫准备本侧 媒体无依据， 又避免了引起 answer转 offer的问题， 克服现有技术的不足。 本发明提出了一种指示终端媒体类型的呼叫方法， 包括以下步骤： 第一 用户终端通过应用月艮务器呼叫第二用户终端； 如果第二用户终端无应答， 则 应用服务器向第三用户终端发送请求消息， 请求消息中携带有关于第一用户 终端的媒体； 第三用户终端基于请求消息中的关于第一用户终端的媒体发起 与第一用户终端之间的协商； 第一用户终端与第三用户终端协商完成后进行 通话。 其中， 当第二用户终端无应答时， 在第一用户终端通过应用月艮务器呼叫 第二用户终端的步骤中， 具体包括以下步骤： 第一用户终端通过应用月艮务器 向第二用户终端发送用于呼叫第二用户终端的请求消息； 第二用户终端接收 到请求消息后， 与第一用户终端进行协商； 协商完成后， 应用服务器等待应 答定时器超时， 取消对第二用户终端的呼叫。 其中， 当第二用户终端无应答时， 在第一用户终端通过应用月艮务器呼叫 第二用户终端的步骤中， 具体包括以下步骤： 第一用户终端向应用月艮务器发 送用于呼叫应用服务器的请求消息； 应用服务器接收到请求消息后与第一用 户终端进行协商， 并在协商完成后与第一用户终端通话； 第一用户终端通过 应用服务器发起到第二用户终端的呼叫； 第二用户终端接收到呼叫后， 与第 一用户终端进行协商； 协商完成后， 应用服务器等待应答定时器超时， 取消 对第二用户终端的呼叫。 其中， 在上述的方法中， 还包括： 如果第二用户终端有应答， 则第二用 户终端与第一用户终端进行通话。 其中， 当第二用户终端有应答时， 在第一用户终端通过应用服务器呼叫 第二用户终端的步骤中， 具体包括以下步骤： 第一用户终端向应用月艮务器发 送用于呼叫应用服务器的请求消息； 应用服务器接收到请求消息后与第一用 户终端进行协商， 并在协商完成后与第一用户终端通话； 第一用户终端通过 应用服务器向第二用户终端发送请求消息， 请求消息中携带有关于第一用户 终端的媒体； 第二用户终端基于请求消息中的关于第一用户终端的媒体发起 与第一用户终端之间的协商； 协商完成后， 应用服务器等待第二用户终端进 行应答。 其中， 第三用户终端或者第二用户终端基于请求消息中的关于第一用户 终端的媒体发起与第一用户终端之间的协商包括： 第三用户终端或者第二用 户终端根据请求消息中的关于第一用户终端的媒体向应用服务器发起提供 offer;应用月艮务器将第三用户终端或者第二用户终端发起的 offer转发给第一 用户终端； 第一用户终端通过应用月艮务器向第三用户终端或者第二用户终端 返回应答 answer„ 其中， 上述请求消息中的媒体具有第一类型标识， 所述具有第一类型标 识的所述媒体与会话初始协议 SIP中定义的具有第二类型标识的媒体不同。 其中 , 第一类型标识为 Content-Disposition： notice-session。 其中， 请求消息中携带的关于第一用户终端的媒体为第一用户终端的媒 体或经应用 艮务器^ ί'爹改后的第一用户终端的媒体。 本发明还提出了一种指示终端媒体类型的呼叫***， 包括： 第一用户终 端、 第二用户终端、 第三用户终端、 和应用月艮务器， 其中， 第一用户终端， 用于通过应用服务器呼叫第二用户终端； 应用服务器， 用于在第二用户终端 无应答的情况下， 向第三用户终端发送请求消息， 请求消息中携带有关于第 一用户终端的具有第一类型标识的媒体； 第三用户终端， 用于基于请求消息 中的关于第一用户终端的媒体发起与第一用户终端之间的协商， 并在协商完 成后与第一用户终端进行通话。 其中， 请求消息中的媒体具有第一类型标识， 具有第一类型标识的媒体 与会话初始协议 SIP中定义的具有第二类型标识的媒体不同。 其中 , 第一类型标识为 Content-Disposition： notice-session。 其中， 请求消息中携带的关于第一用户终端的媒体为第一用户终端的媒 体或经应用 艮务器^ ί'爹改后的第一用户终端的媒体。 釆用本发明的新类型的 SDP ,既解决被叫准备本侧媒体以及协商无依据， 又避免 I起 answer转 offer的问题， 克服现有技术的不足。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部 分， 本发明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的 不当限定。 在附图中： 图 1是根据相关技术的 IMS***参考框架示意图； 图 2是根据相关技术的 IMS域实现用户无应答前转并且新呼叫 INVITE 不携带 SDP的 ¾¾程示意图； 图 3是根据相关技术的 IMS域实现自动台并且新呼叫 INVITE不携带新 类型 SDP的¾¾程示意图； 图 4是根据相关技术的 IMS域实现用户无应答前转并且新呼叫 INVITE 携带 session SDP的流程示意图； 图 5 是根据相关技术的 IMS 域实现自动台并且新呼叫 INVITE 携带 session SDP的¾¾程示意图； 图 6 是根据本发明实施例的 IMS 域实现用户无应答前转并且新呼叫 INVITE携带新类型 SDP的流程示意图； 图 7是才艮据本发明实施例的 IMS域实现自动台并且新呼叫 INVITE携带 新类型 SDP的流程示意图； 图 8是 居本发明实施的***示意图。 具体实施方式 下面结合附图和具体实施方式对本发明作进一步的说明。 为了解决上述问题， 本发明提供了一种新类型的 SDP, 该 SDP通过一定 的标识， 将它与进行媒体协商的 session SDP 区分开来。 比如通过定义 Content-Disposition: notice-session来标识该新类型的 SDP。 该新类型的 SDP的应用场景是： 对于初始 INVITE 中携带 SDP, 但是 AS (业务服务器）发起新呼叫时， 发现初始的 INVITE携带的媒体已经进行 过协商， 再将该 SDP携带放入 INVITE 中呼出到新用户， 则会导致 answer 转 offer。 此时， 将 SDP ^_丈为新类型的 SDP, 然后用 INVITE携带新类型的 SDP发送给新用户， 这样保证被叫回的媒体为一个 offer的媒体， 从而不会 ？ I起 answer转 offer的操作。 仍以无应答前转和自动台为例，介绍釆用新类型的 SDP之后的信令示意 图， 图中仍以可靠传输的 183携带媒体，仍以不支持 precondition (资源预留） 的流程为示例， 但釆用 precondition的流程， 以及使用可靠 180携带媒体， 或者存在 update切换媒体的流程， 与示意流程并无差异， 因此不故累述。 图 6 是根据本发明实施例的 IMS 域实现用户无应答前转并且新呼叫 INVITE携带新类型 SDP的流程示意图， 步骤说明如下： 步骤 601 : UE-A (即第一用户终端） 发起初始会话请求 INVITE消息到 AS , 携带用户 A的 SDP; 步骤 602: AS转发 INVITE给 UE-B (即第二用户终端；)； 步骤 603-604: UE-B回 183响应， 携带用户 B的 SDP; 步-骤 605-606: UE-A回 PRACK消息给 UE-B; 步-骤 607-608: UE-B回 200 ( PRACK ) 消息给 UE-A; 步-骤 609-610: UE-B回 180消息给 UE-A; 用户 B处于振铃中。
AS等待应答定时器超时， 取消到 B的试呼， 然后重新发起到 C的试呼， 下面是具体流程。 步骤 611-614: AS取消到 UE-B的试呼； 步骤 615: AS发起到 UE-C (即第三用户终端） 的呼叫， 携带新类型的 SDP(即关于第一用户终端的具有第一类型标识的媒体 ),通过某类型标识（称 为第一类型标识） 决定该 SDP不作为 session SDP (即 SIP中定义的具有第 二类型标识的媒体 ）， 不参与 offer/answer 的协商过程； 图 中釆用 Content-Disposition: notice-session作为新媒体的标识； 步骤 616: UE-C回 183 , 携带 UE-C的 SDP, 作为 offer的 SDP; 步骤 617: AS将 UE-C的 SDP通过 UPDATE发送给 UE-A; 步骤 618: UE-A回 200, 携带 UE-A的 SDP; 步骤 619: AS发送 PRACK给 UE-C, 携带 UE-A的 SDP, 作为 answer 的 SDP; 步骤 620: UE-C回 200OK; 步骤 621-622: UE-C振铃， 回 180; 用户 C处于振铃状态。 步骤 623-624: UE-C摘机应答， 发送 200OK给 UE-A; 步骤 625-626: UE-A回 UE-C ACK消息；
UE-A与 UE-C进入通话中。 步骤 627-630: UE-C挂机， 通话结束。 其中， 终端媒体类型不改变所述 UE-A与应用月艮务器或 UE-B的协商后 的 offer/answer进展。 图 7是才艮据本发明实施例的 IMS域实现用户自动台流程并且 INVITE携 带 SDP的流程示意图， 步骤说明如下： 步骤 701 : UE-A发起初始会话请求 INVITE消息到 AS , 携带用户 A的 SDP; 步骤 702: AS回 200OK, 携带提示音媒体； 步骤 703 : UE-A回 ACK, UE-A与 AS之间建立通话；
AS放提示音， 并且完成收号过程； 步骤 704: AS发起到 UE-B的呼叫， UE-B的号码由上一步 AS收号得 到； 步-骤 705 : UE-B回 183 , 携带 UE-B的 SDP; 步骤 706: AS将媒体通过 re-INVITE发送给 UE-A; 步-骤 707: UE-A回 200OK, 携带 UE-A的 SDP; 步骤 508: AS将 UE-A的媒体通过 PRACK发送给 UE-B; 步骤 709: UE-B回 200OK ( PRACK ); 步骤 710： AS回 UE- A ACK消息； 步骤 711 : UE-B回 180消息;
UE-B进入振铃状态；
AS等待 UE-B应答定时器超时， 则取消到 UE-B的试呼， 重新收号并发 起到新收用户的呼叫。 步骤 712-715 : AS释放掉向 UE-B的试呼； 步骤 716: AS发起 INVITE, 到 UE-C, 携带新类型的 SDP, 通过某类 型标识决定该 SDP不作为 session SDP, 不参与 offer/answer的协商过程； 图 中釆用 Content-Disposition: notice-session作为新媒体的标 K; 步骤 717: UE-C回 183 , 携带作为 offer的 SDP; 步骤 718: AS将 UE-C的 SDP通过 re-INVITE发送给 UE-A; 步-骤 719: UE-A回 200, 携带 UE-A的 SDP; 步骤 720: AS将媒体 SDP通过 PRACK消息发送给 UE-C, 该 SDP作为 answer; 步骤 721 : UE-C回 200OK; 步骤 722: AS回 ACK; 步骤 723 : UE-C回 180; UE-C处于振铃中。 步骤 724: 被叫摘机， 回 200OK; 步骤 725： AS回 ACK给 UE-C; A、 C用户进入通话中。 步骤 726-729: 呼叫释放。 其中， 发给 UE-C的呼叫请求携带的媒体， 可能为 UE-A媒体， 也可能 为 AS在 UE- A媒体的基础上修改后的媒体， 比如修改里面的 IP、 PORT等。 根据本发明的基本原理， 上述实施例还有其他变换方式， 例如： 新类型 的 SDP通过其它标识而不是 Content-Disposition: notice-session。 显然， 在图 7所示的实施例中， UE-B进入振铃状态后， UE-B进行了应 答， 则步骤 S712至步骤 S729均不会发生。在此种情况的实施例中， 当 UE-A 通过 AS向 UE-B发送 INVITE时仍然会发生被叫 （此时为 UE-B ) 准备本侧 媒体以及协商无依据， 以及 answer转 offer的问题。 因此， 仍然可以釆用本 发明中的新类型的 SDP在步骤 S704中 AS发起 INVITE到 UE-B, 携带新类 型的 SDP , 通过某类型标识决定该 SDP 不作为 session SDP , 不参与 offer/answer的十办商过程； 图中采用 Content-Disposition: notice-session作为新 媒体的标识， 即可解决在该实施例中存在的上述问题。 此时， 该步骤 S704 同上述步骤 S716, 后续步骤 S705至步骤 S708分别同上述步骤 S717至步骤 S720。 本发明还提出了一种指示终端媒体类型的基于 SIP的呼叫***， 参照图 8, 包括： 第一用户终端、 第二用户终端、 第三用户终端、 和应用月艮务器， 其巾， 第一用户终端， 用于通过应用服务器呼叫第二用户终端； 应用服务器， 用于在第二用户终端无应答的情况下， 向第三用户终端发 送请求消息， 请求消息中携带有关于第一用户终端的具有第一类型标识的媒 体； 第三用户终端， 用于基于请求消息中的关于第一用户终端的媒体发起与 第一用户终端之间的协商， 并在协商完成后与第一用户终端进行通话。 其中，请求消息中的媒体具有第一类型标识（例如为 Content-Disposition： notice-session ), 具有第一类型标识的媒体与会话初始协议 SIP中定义的具有 第二类型标识 (即 session SDP ) 的媒体不同。 其中， 请求消息中携带的关于第一用户终端的媒体为第一用户终端的媒 体或经应用 艮务器^ ί'爹改后的第一用户终端的媒体。 领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计 算装置所组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来 实现， 从而， 可以将它们存储在存储装置中由计算装置来执行， 或者将它们 分别制作成各个集成电路模块， 或者将它们中的多个模块或步骤制作成单个 集成电路模块来实现。 这样， 本发明不限制于任何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本 领域的技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的 ^"神和 原则之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护 范围之内。

Claims

权 利 要 求 书 一种指示终端媒体类型的呼叫方法， 其特征在于， 所述方法包括以下步 骤：
第一用户终端通过应用月艮务器呼叫第二用户终端；
如果所述第二用户终端无应答， 则所述应用月艮务器向所述第三用户 终端发送请求消息， 所述请求消息中携带有关于所述第一用户终端的媒 体；
所述第三用户终端基于所述请求消息中的关于所述第一用户终端的 媒体发起与所述第一用户终端之间的协商；
所述第一用户终端与所述第三用户终端协商完成后进行通话。 才艮据权利要求 1所述的方法， 其特征在于， 当所述第二用户终端无应答 时， 在第一用户终端通过应用月艮务器呼叫第二用户终端的步 4聚中， 具体 包括以下步 4聚：
所述第一用户终端通过所述应用月艮务器向所述第二用户终端发送用 于呼叫所述第二用户终端的请求消息；
所述第二用户终端接收到所述请求消息后， 与所述第一用户终端进 行协商；
协商完成后， 所述应用服务器等待应答定时器超时， 取消对所述第 二用户终端的呼叫。 才艮据权利要求 1所述的方法， 其特征在于， 当所述第二用户终端无应答 时， 在第一用户终端通过应用月艮务器呼叫第二用户终端的步 4聚中， 具体 包括以下步 4聚：
所述第一用户终端向所述应用月艮务器发送用于呼叫所述应用月艮务器 的请求消息； 所述应用服务器接收到所述请求消息后与所述第一用户终端进行协 商， 并在协商完成后与所述第一用户终端通话；
所述第一用户终端通过所述应用月艮务器发起到所述第二用户终端的 呼叫； 所述第二用户终端接收到所述呼叫后， 与所述第一用户终端进行协 商；
协商完成后， 所述应用服务器等待应答定时器超时， 取消对所述第 二用户终端的呼叫。 根据权利要求 1所述的方法， 其特征在于， 还包括：
如果所述第二用户终端有应答， 则所述第二用户终端与所述第一用 户终端进行通话。 根据权利要求 4所述的方法， 其特征在于， 当所述第二用户终端有应答 时， 在第一用户终端通过应用月艮务器呼叫第二用户终端的步 4聚中， 具体 包括以下步 4聚：
所述第一用户终端向所述应用月艮务器发送用于呼叫所述应用月艮务器 的请求消息； 所述应用服务器接收到所述请求消息后与所述第一用户终端进行协 商， 并在协商完成后与所述第一用户终端通话；
所述第一用户终端通过所述应用月艮务器向所述第二用户终端发送请 求消息， 所述请求消息中携带有关于所述第一用户终端的媒体；
所述第二用户终端基于所述请求消息中的关于所述第一用户终端的 媒体发起与所述第一用户终端之间的协商；
协商完成后， 所述应用服务器等待所述第二用户终端进行应答。 根据权利要求 1或 5所述的方法， 其特征在于， 所述第三用户终端或者 所述第二用户终端基于所述请求消息中的关于所述第一用户终端的媒体 发起与所述第一用户终端之间的协商包括：
所述第三用户终端或者所述第二用户终端 居所述请求消息中的关 于所述第一用户终端的媒体向所述应用服务器发起提供 offer;
所述应用月艮务器将所述第三用户终端或者所述第二用户终端发起的 所述 offer转发给所述第一用户终端；
所述第一用户终端通过所述应用月艮务器向所述第三用户终端或者所 述第二用户终端返回应答 answer。
7. 根据权利要求 1至 5中任一项所述的方法， 其特征在于， 所述请求消息 中的所述媒体具有第一类型标识， 所述具有第一类型标识的所述媒体与 会话初始协议 SIP中定义的具有第二类型标识的媒体不同。
8. 根据权利要求 7 所述的方法， 其特征在于， 所述第一类型标识为 Content-Disposition： notice-session。
9. 根据权利要求 1至 5中任一项所述的方法， 其特征在于， 所述请求消息 中携带的关于所述第一用户终端的所述媒体为所述第一用户终端的媒体 或经所述应用月艮务器爹改后的所述第一用户终端的媒体。
10. —种指示终端媒体类型的呼叫***， 其特征在于， 包括： 第一用户终端、 第二用户终端、 第三用户终端、 和应用服务器， 其中， 所述第一用户终端， 用于通过所述应用月艮务器呼叫所述第二用户终 端；
所述应用月艮务器， 用于在所述第二用户终端无应答的情况下， 向所 述第三用户终端发送请求消息， 所述请求消息中携带有关于所述第一用 户终端的媒体；
所述第三用户终端， 用于基于所述请求消息中的关于所述第一用户 终端的媒体发起与所述第一用户终端之间的协商， 并在协商完成后与所 述第一用户终端进行通话。
11. 根据权利要求 10所述的***， 其特征在于， 所述请求消息中的所述媒体 具有第一类型标识， 所述具有第一类型标识的所述媒体与会话初始协议 SIP中定义的具有第二类型标识的媒体不同。
12. 居权利要求 11 所述的***， 其特征在于， 所述第一类型标识为 Content-Disposition： notice-session。
13. 根据权利要求 10所述的***， 其特征在于， 所述请求消息中携带的关于 所述第一用户终端的所述媒体为所述第一用户终端的媒体或经所述应用 月艮务器^ ί'爹改后的所述第一用户终端的媒体。
PCT/CN2010/075291 2009-08-25 2010-07-20 一种指示终端媒体类型的呼叫方法及*** WO2011023041A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2009101675605A CN101998325A (zh) 2009-08-25 2009-08-25 一种指示终端媒体类型的呼叫方法及装置
CN200910167560.5 2009-08-25

Publications (1)

Publication Number Publication Date
WO2011023041A1 true WO2011023041A1 (zh) 2011-03-03

Family

ID=43627231

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/075291 WO2011023041A1 (zh) 2009-08-25 2010-07-20 一种指示终端媒体类型的呼叫方法及***

Country Status (2)

Country Link
CN (1) CN101998325A (zh)
WO (1) WO2011023041A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102904882B (zh) * 2012-09-24 2018-08-10 南京中兴新软件有限责任公司 随机呼叫的转发方法及装置
CN103475648B (zh) * 2013-08-29 2017-12-19 上海斐讯数据通信技术有限公司 基于sip协议的呼叫盲转方法及呼叫盲转***
CN106658752B (zh) * 2015-11-03 2020-04-14 ***通信集团公司 一种通信资源确认方法、装置及***
CN107371140B (zh) * 2016-05-11 2021-01-12 ***通信有限公司研究院 一种呼叫前转的处理方法及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101123824A (zh) * 2007-09-12 2008-02-13 华为技术有限公司 多媒体通信方法及网元设备
CN101227303A (zh) * 2007-01-19 2008-07-23 中兴通讯股份有限公司 彩铃和彩像发送方法以及早媒体发送方法
CN101433036A (zh) * 2006-04-26 2009-05-13 三星电子株式会社 在因特网协议多媒体子***网络中转发用户设备的性能信息的方法和***

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1893427A (zh) * 2005-07-07 2007-01-10 华为技术有限公司 一种进行业务支持能力协商的方法
CN101448222B (zh) * 2008-04-01 2012-05-09 中兴通讯股份有限公司 一种实现ims集中业务被叫转接的方法
CN101459897A (zh) * 2008-04-17 2009-06-17 中兴通讯股份有限公司 一种前转业务中的媒体协商方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101433036A (zh) * 2006-04-26 2009-05-13 三星电子株式会社 在因特网协议多媒体子***网络中转发用户设备的性能信息的方法和***
CN101227303A (zh) * 2007-01-19 2008-07-23 中兴通讯股份有限公司 彩铃和彩像发送方法以及早媒体发送方法
CN101123824A (zh) * 2007-09-12 2008-02-13 华为技术有限公司 多媒体通信方法及网元设备

Also Published As

Publication number Publication date
CN101998325A (zh) 2011-03-30

Similar Documents

Publication Publication Date Title
US10044553B2 (en) Media resource reservation request failure handling for voice over mobile wireless network
AU2011374206B2 (en) Methods and apparatuses for enabling an Single Radio Voice Call Continuity (SRVCC) access transfer of an emergency call back session
US8717876B2 (en) Providing packet-based multimedia services via a circuit bearer
EP2192742B1 (en) Local session controller, ip multimedia subsystem and session registration method
EP1973283A1 (en) Interworking network element, interworking system between the csi terminal and the ims terminal and the method thereof
US8494527B2 (en) Method for transferring a communication session in a telecommunications network from a first connection to a second connection
WO2013044649A1 (zh) 电信网络向互联网提供会话服务的方法及***
WO2006099815A1 (fr) Procede d'enregistrement d'un utilisateur dans le sous-systeme multimedia ip et systeme associe
US9055397B2 (en) Method for usage of VPLMN infrastructure by an HPLMN to terminate an IMS session set up for a roaming user
US20100284267A1 (en) Call set-up in a communication network
JP2011505713A (ja) インターネット・プロトコル・マルチメディア・コア・ネットワーク・サブシステムにおけるアプリケーションサーバによる発呼
WO2008025257A1 (fr) Procédé d'intercommunication et système de communication entre différents réseaux
EP1875714A2 (en) Session initiation from application servers in an ip multimedia subsystem
WO2013044631A1 (zh) 融合呼叫方法及***
US20150334241A1 (en) Real-Time Monitoring/Interrupting of Voicemail Message Recording
RU2510584C2 (ru) Способ, устройство и система для реализации сервиса оверрайда при экстренном вызове
EP2119178B1 (en) Method and apparatuses for the provision of network services offered through a set of servers in an ims network
WO2011023041A1 (zh) 一种指示终端媒体类型的呼叫方法及***
WO2011107001A1 (zh) 呼叫的处理方法和装置
WO2017000481A1 (zh) 语音通话的拨号方法和装置
WO2009135375A1 (zh) 实现单对话彩铃业务的呼叫建立方法
WO2011032425A1 (zh) 呼叫等待业务中区别振铃的实现方法及***
WO2012171290A1 (zh) 询问转接实现方法、应用服务器、业务终端和***
WO2010054558A1 (zh) 一种实现多媒体铃音业务安全机制的方法、设备及***
KR20120044680A (ko) 회의 통화 서비스 제공을 위한 패킷 서비스 시스템 및 부가서비스 제어기, 그리고 그의 회의 통화 서비스 제공 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10811201

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10811201

Country of ref document: EP

Kind code of ref document: A1