IMSVOIP业务呼叫流程
IMS sip呼叫流程
3GPP2 X.S0013-009-0Version: 1.0Date: December 2007IMS/MMD Call Flow ExamplesCOPYRIGHT3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner’s name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at secretariat@. Requests to reproduce individual Organizational Partner’s documents should be directed to that Organizational Partner. See for more information.X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples Revision HistoryRevision Changes Date v1.0 Initial Publication December, 2007IMS/MMD Call Flow Examples1CONTENTS23Revision History ii 41Introduction 4 2Glossary and Definitions 5 562.1Acronyms 5 72.2Definitions 53References 6 893.1Normative References 6 103.2Informative References 64Methodology 711124.1Functional Entities covered by call flows 7 134.2Identities 7 144.2.1User and Network Identities (7)154.3Notation for call flows 8 165Registration Procedures 8 6Signaling flows for session establishment 917186.1General assumptions 9 196.2Scenarios 96.2.1Scenario 1 (9)20216.2.1.1Assumptions (10)226.2.1.2Call Flow (10)6.2.2Scenario 2 (15)236.2.2.1Assumptions (15)246.2.2.2Call Flow (15)256.2.3Scenario 3 (16)266.2.3.1Assumptions (16)27286.2.3.2Call flow (16)296.2.4Scenario 4 (23)306.2.4.1Assumptions (23)316.2.4.2Call flow (23)32Appendix A (Informative): VoIP example with QoS reservation, activation, and updating at RAN 31A.1QoS Configuration for VoIP in advance 3133A.2Resource activation on originating side 3334A.3Resource activation on terminating side 34351A.4Updating of resource reservation 35 2A.4.1Resource updating on originating side 35A.4.2Resource updating on terminating side 37 34LIST OF FIGURES1Figure 1 Originating UE resource ready, terminating UE resource ready (10)23Figure 2 Originating UE resource ready, terminating UE resource not ready (15)4Figure 3 Originating UE not ready, Terminating UE ready (17)5Figure 4 Originating UE not ready, Terminating UE not ready (24)6Figure 5 QoS configuration for VoIP (32)Figure 6 QoS Activation on Originating UE (33)78Figure 7 QoS Activation on Terminating UE (34)9Figure 8 Resource Updating on Originating UE (36)Figure 9 Resource Updating on Terminating UE (37)10111 Introduction12The document provides examples of signaling flows for the IP multimedia call control based on 3SIP and SDP. The signaling flows specified in this document are only for informational purposes.If there is ambiguity between this specification and [1], the text specified in [1] shall be followed. 45The call flows describe the behavior of the mobile stations under various conditions for setting up 6real time services like VoIP and PSVT.7In this document, several key words are used to signify the requirements. The key words “shall”, 8“shall not”, “should”, “should not” and “may” are to be interpreted as described in [6] and the TIA 9Engineering Style Manual.X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples2 Glossary and Definitions12.1 Acronyms2 AAA Authentication, Authorization, and Accounting3AN Access Network 4 AT Access Terminal 5 EMPA Enhanced Multi-Flow Packet Application 6 HRPD High Rate Packet Data 7 HSS Home Subscriber Server 8 IMS IP Multimedia Subsystem9 IP Internet Protocol 10 IP-CAN IP-Connectivity Access Network 11 MMD Multi Media Domain 12 MPA Multi-Flow Packet Application 13 PDSN Packet Data Serving Node 14 PFO PPP Free Operation 15 PPP Point to Point Protocol 16 PSVT Packet Switched Video Telephony 17 QoS Quality of Service 18 RAN Radio Access Network19 RSVP Resource ReSerVation Protocol 20 SBBC Service Based Bearer Control 21 SDP Session Description Protocol 22 SIP Session Initiation Protocol 23 TFT Traffic Flow Template 24 UDP User Datagram Protocol 25 UE User Equipment 26 VoIP Voice Over IP27 2.2 Definitions28 CallerThe person placing a call29 Called party The recipient or destination of a call30 AlertThe audible notification given to the Called party of an incoming call. 31 Ring BackThe audible notification given to a Caller to indicate that the Called 32 party has been located and is being alerted333 References12The following documents contain provisions, which, through reference in this text, constitute 3provisions of this document.4References are either specific (identified by date of publication, edition number, version 5number, etc.) or non-specific.6For a specific reference, subsequent revisions do not apply.7For a non-specific reference, the latest version applies. In the case of a reference to a 83GPP2 document, a non-specific reference implicitly refers to the latest version of that 9document in the same Release as the present document.References3.1 Normative1011[1]3GPP2 X.S0013-004-A v1.0: “IP Multimedia Call Control Protocol Based on SIP and SDP 12Stage 3”.13[2]3GPP2 X.S0013-002-A v1.0: “IP Multimedia (IM) Subsystem – Stage 2”.14[3]IETF RFC 2429, “ RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video15(H.263+)”.16[4]IETF RFC 3558, “RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and 17Selectable Mode Vocoders (SMV)”.18[5]IETF RFC 3262, “Reliability of provisional Responses in the Session Initiation Protocol(SIP)”1920[6]IETF RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels”, March 1997.21[7]3GPP2 X.S0013-005-A v1.0: “All-IP Core Network Multimedia Domain IP Multimedia 22Subsystem Cx Interface Signaling flows and Message Contents” – Annex A.23References3.2 Informative242526[8] 3GPP2 X.S0013-012-0 v1.0: “All-IP Core Network Multimedia Domain; Service Based 27Bearer Control – Stage 2”.28X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples4 Methodology14.1 Functional Entities covered by call flows23The flows show the signaling exchanges between the following functional entities:45User Equipment (UE)6Proxy-CSCF (P-CSCF)7Interrogating-CSCF (I-CSCF)8Serving-CSCF (S-CSCF)910The call flows mainly show the interactions between the UE-1 and UE-2 for call origination and 11termination. The procedures and the message exchanged between these elements are as described in [1].124.2 Identities134.2.1 User and Network Identities1415The public identity of UE-1 is sip:UE-1@. The public identity of UE-2 issip:UE-2@161718The following are network entities associated with UE-1:1920Home Domain of UE-1: 21P-CSCF serving UE-1: 22I-CSCF serving UE-1: 23S-CSCF serving UE-1: 24The following are the network entities associated with UE-2:2526Home Domain of UE-2: 27P-CSCF serving UE-2: 28I-CSCF serving UE-2: 29S-CSCF serving UE-2: 3031In the example session establishment flows, both UE-1 and UE-2 are assumed to be in the home 32network. So, the P-CSCF1 and P-CSCF2 are in UE-1’s and UE-2’s respective home networks.33However, according to [2], the P-CSCF can be either in the home or visited network. The session 34establishment call flows described in this document are not affected whether the P-CSCF is in the 35visited or home network.36For brevity, I-CSCF and S-CSCF are shown together in the session establishment call flows.4.3 Notation for call flows12Offer/Answer exchange process is also shown in the call flows. For brevity, the following notation is used to 3represent offer and answer:4•“O” and “A” in the call flows represent “Offer” and “Answer”.5•“O n” represents the n th SDP offer. For example, if there are two offer/answer exchanges during the call 6setup process, then the first offer will be noted as “O1” and the second as “O2”.7•“A n” represents the n th SDP Answer. Answer “A n” corresponds to Offer “O n”.891011Procedures5 Registration1213The registration procedures for UE-1 and UE-2 are as specified in [1] and [7]. UE-1 registers with 14S-CSCF1 through P-CSCF1 and UE-2 registers with S-CSCF2 through P-CSCF2.1516171 6 Signaling flows for session establishment2 In all of the call flows provided in this document, registration procedures are assumed to have already been3 completed. 45 6.1 General assumptions6All the call flows shown in this document assume the following:7 • The originating UE and the terminating UE both support precondition and reliable provisional responses8 100 (rel).9 • The originating UE will only include “Supported: precondition” in the SIP INVITE it sends out to its peer.10 o If the originating UE wishes to both send and receive media with its peer, and the resources are11 reserved for the stream, the originating UE marks the stream as sendrecv using the “a=sendrecv” 12 attribute. (Note: for sendonly streams, the originating UE marks the stream as “a=sendonly” and 13 for recvonly streams, the originating UE marks the stream as “a=recvonly”).14 o If the originating UE wishes to communicate with its peer, and the resources are not reserved for15 the stream, the originating UE marks the particular stream as inactive using the “a=inactive” 16 attribute.17 • If the “Supported” header in the incoming INVITE includes “precondition” and the terminating UE decides18 to use precondition, the terminating UE includes “Require: precondition” in all reliable responses that carry 19 SDP (i.e., offer or answer).20 • The terminating UE sends 180 (Ringing) response reliably. Note that sending the 180 (Ringing) response21 reliably does not increase the call setup time experienced by the caller.22 • If the 180 (Ringing) response contains an answer (or offer), the called party is alerted only after receiving a23 PRACK request for the 180 (Ringing) response. This enhances the caller/called party user experience. For 24 example, if the called party picks up the phone before the 180 (Ringing) response reaches the caller, the 25 caller will only be able to hear the called party but will not be able to respond,26 • Both UEs have the required resources ready before the terminating UE can alert the called party of an27 incoming call.28 • For brevity, 100 (Trying) messages are not shown in the figures. 29 • The SBBC interactions [8] are not shown in the call flows. 3031 6.2 Scenarios32 The following scenarios are considered for the session establishment process:33 • Scenario 1: Originating UE has resources ready before sending INVITE, terminating UE has resources34 ready before sending the first provisional response;35 • Scenario 2: Originating UE has resources ready before sending INVITE, terminating UE does not have36 resources ready before sending the first provisional response;37 • Scenario 3: Originating UE does not have resources ready before sending INVITE, terminating UE has38 resources ready before sending the first provisional response;39 • Scenario 4: Originating UE does not have resources ready before sending INVITE, terminating UE does40 not have resources ready before sending the first provisional response.4142 The call flows for the above four scenarios are depicted in the subsequent subsections.43 6.2.1 Scenario 144 This section covers the scenario where the originating UE’s resources are ready before sending INVITE, and the45terminating UE’s resources are ready before sending the first provisional response.126.2.1.1 Assumptions3Flow6.2.1.2 Call45The following section applies to the case where UE-1 has its resource ready before sending the6INVITE request to UE-2. The terminating UE, UE-2, also has its resource ready before answering theINVITE request with the first provisional response.789Note: This flow assumes UE-2 has sufficient resources available prior to receiving the INVITE.101112Figure 1 Originating UE resource ready, terminating UE resource ready131. INVITE (UE-1 to P-CSCF1)1415UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds an SDP offer16containing characteristics of each codec, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices 1718offered.19For this example, it is assumed that UE-1 is willing to establish a multimedia session comprising a video stream and2021an audio stream. The video stream supports one H.263 codec as specified in [3]. The audio stream supports both22EVRC and SMV codecs as specified in [4].2324In addition, UE-1 indicates that precondition is supported for this session. In the SDP offer, it indicates that resource25is already available at the local end point.Table 6.2.1.2-1 INVITE (UE-1 to P-CSCF1)1INVITE sip:UE-2@ SIP/2.0From: <sip:UE-1@>;tag=169f498-0-13c4-78e-2044f20e-78eTo: <sip:UE-2@>Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100CSeq: 1 INVITEVia: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348Max-Forwards: 70Route: <sip::7531;lr;comp=sigcomp>, <sip:;lr>P-Preferred-Identity: "User-1" <sip:UE-1@>P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411Privacy: noneRequire: sec-agreeProxy-Require: sec-agreeSecurity-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=98765432; spi-s=76543210;port-c=13579; port-s=23456Contact: <sip:UE-1@10.20.1.100:1357;comp=sigcomp>Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGESupported: 100rel, preconditionContent-Type: application/sdpContent-Length: xxxv=0o=- 3323527065117000 3323527065117000 IN IP4 10.20.1.100s=-c=IN IP4 10.20.1.100t=0 0m=audio 49500 RTP/AVP 97 99b=AS:25.4a=curr:qos local sendrecva=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecva=rtpmap:97 EVRC/8000a=ptime:20a=rtpmap:99 SMV/8000m=video 49600 RTP/AVP 34b=AS:75a=curr:qos local sendrecva=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecva=rtpmap:34 H263/90000a=cif:1232. INVITE (P-CSCF1 to I/S-CSCF1)4The P-CSCF1 adds itself to the Record-Route header and Via header. As the request is forwarded to an interface that 5is not compressed, the P-CSCF1 SIP URI does not contain the "comp=sigcomp" parameter. The P-CSCF1 removes 6the Security-Verify header and associated "sec-agree" option-tags prior to forwarding the request. As the Require 7and Proxy-Require headers are empty, P-CSCF1 removes those headers completely.8The INVITE request is forwarded to the I/S-CSCF1.910113. INVITE (I/S-CSCF1 to I/S-CSCF2)12S-CSCF1 performs an analysis of the destination address, and determines the network operator to whom the 13destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration 14hidden, S-CSCF1 forwards the INVITE request directly to I-CSCF2 in the destination network.1516The I-CSCF2 sends a query to the HSS to find out the S-CSCF2 of the called user. The HSS responds with the1address of the current S-CSCF2 for the terminating subscriber. I-CSCF2 forwards the INVITE request to the2S-CSCF2 that will handle the session termination. S-CSCF2 validates the service profile of this subscriber and3evaluates the initial filter criteria.454-5. INVITE (I/S-CSCF2 to UE-2)S-CSCF2 forwards the INVITE request to UE-2 via P-CSCF2.6786. 180 Ringing (UE-2 to P-CSCF2)9UE-2 has accepted both video and audio streams, and EVRC is the chosen codec for the audio stream. Since10resources are already available for UE-2, it sends a 180 (Ringing) response reliably with the SDP answer indicating11that resources are reserved at both endpoints.127-10. 180 Ringing (P-CSCF2 to UE-1)1314P-CSCF2 forwards the 180 (Ringing) response to UE-1 via I/S-CSCF2, I/S-CSCF1, and P-CSCF1. Table 6.2.1.2-215shows the 180 (Ringing) response in detail.1617Table 6.2.1.2-2 180 Ringing (P-CSCF1 to UE-1)SIP/2.0 180 RingingFrom: <sip:UE-1@>;tag=169f498-0-13c4-78e-2044f20e-78eTo: <sip:UE-2@>;tag=169f7f8-0-13c4-9f6-33835972-9f6Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100CSeq: 1 INVITEVia: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348Record-Route:<sip:;lr>,<sip:;lr>,<sip:;lr>, <sip::7531;lr;comp=sigcomp>Contact: <sip:UE-2@10.30.1.24:8805;comp=sigcomp>P-Asserted-Identity: "User 2" <sip:UE-2@>, <tel:+1-858-335-7341>Privacy: noneAllow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGERequire: 100rel, preconditionRSeq: 1000Content-Type: application/sdpContent-Length: xxxv=0o=- 33235270718000 33235270718000 IN IP4 10.30.1.24s=-c=IN IP4 10.30.1.24t=0 0m=audio 49700 RTP/AVP 97a=curr:qos local sendrecva=curr:qos remote sendrecva=des:qos optional local sendrecva=des:qos optional remote sendrecva=rtpmap:97 EVRC/8000a=ptime:20m=video 49702 RTP/AVP 34a=curr:qos local sendrecva=curr:qos remote sendrecva=des:qos optional local sendrecva=des:qos optional remote sendrecva=rtpmap:34 H263/90000a=cif:118192011. PRACK (UE-1 to P-CSCF1)21UE-1 acknowledges the 180 (Ringing) response from UE-2 with a PRACK request as specified in [5]. (Table6.2.1.2-3)2223If UE-1 determines to make any change in media flows, it includes a new SDP offer in the PRACK request sent to 12UE-2. Otherwise, no SDP offer is included in the PRACK request.3Table 6.2.1.2-3 PRACK (UE-1 to P-CSCF1)4PRACK sip:UE-2@10.30.1.24:8805;comp=sigcomp SIP/2.0From: <sip:UE-1@>;tag=169f498-0-13c4-78e-2044f20e-78eTo: <sip:UE-2@>; tag=169f7f8-0-13c4-9f6-33835972-9f6Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100P-Access-Network-Info: 3GPP2-1X-HRPD;ci-3gpp2=1234123412341234123412341234123411CSeq: 2 PRACKVia: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348Max-Forwards: 70Route:<sip::7531;lr;comp=sigcomp>,<sip:;lr>,<sip:scscf2.d ;lr>,<sip:;lr>RAck: 1000 1 INVITEContent-Length: 05612. PRACK (P-CSCF1 to I/S-CSCF1)7The P-CSCF forwards the PRACK request to S-CSCF. As the Proxy-Require header is empty, the P-CSCF removes this header completely.891013-14. PRACK (I/S-CSCF1 to P-CSCF2)The I/S-CSCF1 forwards the PRACK request to P-CSCF2 via I/S-CSCF2.11121315. PRACK (P-CSCF2 to UE-2)UE-2 starts alerting the user after it receives the PRACK request for the 180 (Ringing) response. UE-2 may also1415alert the user before receiving the PRACK request, but there may be media clipping if the user answers the call before the 180 (Ringing) response reaches UE-1.16171816. 200 OK (UE-2 to P-CSCF2)19The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request.202117-20. 200 OK (P-CSCF2 to UE-1)22The P-CSCF2 forwards the 200 OK response to UE-1 via I/S-CSCF2, I/S-CSCF1, and P-CSCF1. Table 6.2.1.2-4 23shows the 200 OK message going from P-CSCF1 to UE-1.2425Table 6.2.1.2-4 200 OK (P-CSCF1 to UE-1)SIP/2.0 200 OKFrom: <sip:UE-1@>;tag=169f498-0-13c4-78e-2044f20e-78eTo: <sip:UE-2@>;tag=169f7f8-0-13c4-9f6-33835972-9f6Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100CSeq: 2 PRACKVia: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348Content-Length: 0262721. 200 OK (UE-2 to P-CSCF2)28When the user at UE-2 answers the call, UE-2 generates a 200 OK response towards UE-1 to answer the INVITE 29request.303122-25. 200 OK (P-CSCF2 to UE-1)The P-CSCF2 forwards the 200 OK response to UE-1 via I/S-CSCF2, I/SCSCF1, and P-CSCF1. Table 6.2.1.2-53233shows the 200 OK message going from P-CSCF1 to UE-1.Table 6.2.1.2-5 200 OK (P-CSCF1 to UE-1)1 SIP/2.0 200 OKFrom: <sip:UE-1@>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@>;tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 1 INVITERecord-Route:<sip:;lr>,<sip:;lr>,<sip:;lr>,<sip::7531;lr;comp=sigcomp>Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Contact: <sip:UE-2@10.30.1.24:8805;comp=sigcomp> Content-Length: 02 26. ACK (UE-1 to P-CSCF1)3 UE responds to the 200 OK with an ACK request sent to P-CSCF1. (Table 6.2.1.2-6).4 Table 6.2.1.2-6 ACK (UE-1 to P-CSCF1)567 27-30. ACK (P-CSCF1 to UE-2)8 The P-CSCF1 forwards the ACK response to UE-2 via I/S-CSCF1, I/S-CSCF2, and P-CSCF2.9 ACK sip:UE-2@10.30.1.24:8805;comp=sigcomp SIP/2.0From: <sip:UE-1@>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@>;tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 1 ACKVia: SIP/2.0/UDP 10.20.1.100:5060;comp=sigcomp;branch=z9hG4bK-792-1d9290-49ff0c31 Max-Forwards: 70Route: <sip::7531;lr;comp=sigcomp>,<sip:;lr>, <sip:;lr>, <sip:;lr> Content-Length: 0126.2.2 Scenario23This section covers the scenario where the originating UE’s resources are ready before sending INVITE, and the 4terminating UE’s resources are not ready before sending the first provisional response566.2.2.1 Assumptions7Flow6.2.2.2 Call89This scenario assumes that the terminating UE, UE-2, does not have the resource ready before sending the first 10provisional response. UE-2 may send a 183 (Session Progress) response unreliably. At the same time, UE-2 also 11starts the resource reservation process. Once the resource is ready at UE-2 side, the UE-2 sends 180 (Ringing) 12response reliably to UE-1, including an SDP answer to indicate that the resource is ready. The SDP offer/answer 13exchanges are the same as those in Scenario 1.1415Figure 2 Originating UE resource ready, terminating UE resource not ready16136.2.3 Scenario23This section covers the scenario where the originating UE’s resources are not ready before sending INVITE, and 4terminating UE’s resources are ready before sending the first provisional response.56.2.3.1 Assumptions6The call flow in this section assumes that the originating UE, UE-1, has resources ready before sending the PRACK 7request to the first provisional response. In case UE-1’s resources are not ready before sending the PRACK request 8for the first provisional response (183), then UE-1 needs to send an UPDATE request to UE-2 to indicate that 9resources are ready, after the resource reservation is completed.10flow6.2.3.2 Call1112The following section applies to the case where UE-1 has no resource reserved before sending the initial INVITE 13request to UE-2.141512Figure 3 Originating UE not ready, Terminating UE ready31-5. INVITE (UE-1 to P-CSCF1)45UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds a SDPcontaining characteristics of each codec, and assigns local port numbers for each possible media flow. Multiple 67media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices8offered.9For this example, it is assumed that UE-1 desires to establish a multimedia session comprising a video stream and an1011audio stream. The video stream supports one H.263 codec. The audio stream supports both EVRC and SMV codec.1213UE-1 does not indicate that precondition is required for this session, but indicates that it is supported. (This approachoptimizes compatibility and performance when interworking with 3rd party (non-MMD) terminals). In the SDP body,1415UE-1 indicates the current resource status and that the desired resource status is optional. UE-1 also sets every media stream to inactive mode by using the ‘a=inactive’ SDP attribute in the SDP offer. Detecting the QoS precondition 16content in the SDP, UE-2 indicates resource reservation, but the session can continue regardless of whether or not 17this reservation is possible.1819UE-1 does not indicate that reliable provisional responses are required, but indicates that they are supported. This2021gives UE-2 the ability to reliably send only those responses that are most appropriate.12Table 6.2.3.2-7 INVITE (UE-1 to P-CSCF1)INVITE sip:UE-2@ SIP/2.0Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348From: <sip:UE-1@>;tag=a48sTo: <sip:UE-2@>Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@CSeq: 1 INVITEMax-Forwards: 70Route: <sip::7531;lr;comp=sigcomp>, <sip:;lr>P-Preferred-Identity: "User-1" <sip:UE-1@>P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411Privacy: noneContact: <sip:UE-1@100.200.1.1:1357;comp=sigcomp>Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGERequire: sec-agreeProxy-Require: sec-agreeSupported: 100rel, preconditionSecurity-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=9876543; spi-s=3456789;port-c=8642; port-s=7531Content-Type: application/sdpContent-Length: xxxv=0o=- 2987935614 2987935614 IN IP4 100.200.1.1s=-c=IN IP4 100.200.1.1t=0 0m=audio 10500 RTP/AVP 97 99b=AS:25.4a=inactivea=curr:qos local nonea=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecva=rtpmap:97 EVRC/8000a=ptime:20a=rtpmap:99 SMV/8000m=video 10600 RTP/AVP 34b=AS:75a=inactivea=curr:qos local nonea=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecva=rtpmap:34 H263/90000a=cif:1346-10. 183 (P-CSCF1 to UE-1)5UE-2 accepts both video and audio streams, and chooses EVRC as the codec for the audio stream. An SDP answer is 6included to assist UE-1 in completing resource reservation as early as possible. The SDP answer includes precondition status.781Table 6.2.3.2-8 183 Session Progress (P-CSCF1 to UE-1)SIP/2.0 183 Session ProgressVia: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch= z9hG4bK4d29348From: <sip:UE-1@>;tag=a48sTo: <sip:UE-2@>;tag=a9f6Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@CSeq: 1 INVITERecord-Route:<sip:;lr>,<sip:;lr>,<sip:;lr>,<sip::7531;lr;comp=sigcomp>Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp>P-Asserted-Identity: "User 2" <sip:UE-2@>, <tel:+1-972-321-9876>Privacy: noneAllow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGERequire: 100rel, preconditionRSeq: 1000Content-Type: application/sdpContent-Length: xxxv=0o=- 35270718123 35270718123 IN IP4 100.300.1.2s=-c=IN IP4 100.300.1.2t=0 0m=audio 10700 RTP/AVP 97b=AS:25.4a=inactivea=curr:qos local sendrecva=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecva=conf:qos remote sendrecva=rtpmap:97 EVRC/8000a=ptime:20m=video 10702 RTP/AVP 34b=AS:75a=inactivea=curr:qos local sendrecva=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecva=conf:qos remote sendrecva=rtpmap:34 H263/90000a=cif:12311-15. PRACK (UE-1 to P-CSCF1)4UE-1 acknowledges the 183 (Session Progress) response from UE-2 with a PRACK request. Resource reservation at 5UE-1 is assumed to have been completed at some point prior to sending the PRACK request. The local resource 6status is included in the SDP offer.78。
IMS业务流程介绍
IMS业务流程介绍首先是用户注册。
在IMS中，用户需要进行注册才能使用该系统提供的各种多媒体服务。
用户注册包括认证和位置注册两个过程。
认证过程是通过提供用户的身份信息和密码进行验证，确认用户的身份合法性。
位置注册过程是用户在网络中的位置登记，以便网络能够正确地处理用户进行的呼叫和其他服务请求。
一旦用户注册成功，就可以建立呼叫。
IMS支持多种呼叫类型，包括点对点呼叫、多方呼叫、视频呼叫等。
呼叫建立过程包括寻址、呼叫信令传输、媒体协商等环节。
首先，寻址过程确定用户的IP地址和服务能力，以及呼叫目的地的IP地址和服务能力。
然后，呼叫信令传输过程使用SIP（Session Initiation Protocol）进行呼叫的建立和释放。
最后，在呼叫建立过程中进行媒体协商，例如确定音视频编解码方式、媒体传输参数等。
一旦呼叫建立，用户可以使用各种服务。
IMS支持多种多媒体服务，包括语音通话、视频通话、实时消息、文件传输、在线游戏等。
通过IMS，用户可以选择并使用所需的服务。
服务控制过程包括服务请求、服务识别、服务授权和服务计费等环节。
用户可以通过设备上的用户界面发起服务请求，然后IMS系统根据服务请求中的服务识别信息，对用户的请求进行验证和授权。
一旦服务授权通过，IMS系统会提供相应的服务，并记录用户使用的服务量，以进行计费。
最后是呼叫释放。
呼叫释放可以是用户主动发起的，也可以是系统发起的。
用户主动发起呼叫释放时，可以通过设备上的用户界面发送释放请求，然后IMS系统进行呼叫释放的处理。
系统发起呼叫释放时，可能是由于呼叫过程中发生了错误或异常情况，例如呼叫建立失败、服务控制失败等。
IMS系统会向用户发送释放信令，告知用户呼叫释放的原因。
综上所述，IMS的业务流程包括用户注册、呼叫建立、服务控制和呼叫释放等环节。
用户通过注册来使用IMS提供的多媒体服务，通过呼叫建立来进行通话或其他服务，通过服务控制来验证授权和计费，通过呼叫释放来结束通话。
ims呼叫流程
ims呼叫流程IMS呼叫流程。
IMS（IP Multimedia Subsystem）是一种基于IP网络的多媒体子系统，它为各种多媒体服务提供了一个统一的处理平台。
在IMS网络中，呼叫流程是非常重要的一环，它涉及到用户之间的通信建立和维护。
下面将介绍IMS呼叫流程的详细步骤。
首先，当用户A拨打用户B的号码时，呼叫请求首先到达用户A所在的本地IMS网络。
本地IMS网络会对呼叫请求进行鉴权和鉴权，确保用户A有权进行呼叫操作。
一旦鉴权通过，本地IMS网络会向用户B所在的本地IMS网络发送呼叫请求。
接下来，用户B所在的本地IMS网络收到呼叫请求后，会再次进行鉴权和鉴权，确保用户B有权接听呼叫。
如果鉴权通过，用户B的终端会响铃，提示用户B有呼叫请求。
当用户B接听呼叫后，用户A和用户B之间的媒体流开始建立。
本地IMS网络会为用户A和用户B之间的通话建立一个会话，并负责会话的传输和维护。
在通话过程中，本地IMS网络会监控通话质量，确保通话畅通无阻。
最后，在通话结束时，用户A或用户B挂断电话，本地IMS网络会释放会话资源，结束通话。
同时，本地IMS网络会向对方发送挂断消息，通知对方通话已经结束。
总的来说，IMS呼叫流程包括呼叫请求的发起、鉴权和鉴权、呼叫接听、媒体流建立和通话结束等步骤。
通过这些步骤，IMS网络能够实现用户之间的多媒体通信，为用户提供高质量的通话体验。
在实际应用中，IMS呼叫流程还可能涉及到一些特殊情况的处理，比如用户不在线、用户忙线、用户拒接等情况。
针对这些情况，IMS网络会有相应的处理机制，确保呼叫流程能够顺利进行。
总之，IMS呼叫流程是IMS网络中非常重要的一环，它直接影响到用户之间通信的质量和稳定性。
只有对IMS呼叫流程有深入的了解，才能更好地设计和优化IMS网络，为用户提供更好的通信服务。
希望本文对IMS呼叫流程有所帮助，谢谢阅读。
volte呼叫信令流程
一、终端开机的IMS注册过程：用户开机以后，首先完成附着过程，附着完成以后，发起IMS注册过程。
在IMS注册流程中，先建立QCI=5的SIP信令承载。
然后进行SIP的注册过程，当完成注册过程以后，就可以进行VoLTE呼叫了。
SIP信令的注册过程如下图所示。
二、VoL TE呼叫VoL TE的信令呼叫流程：三、Volte呼叫volte的AMR-WB 12.65K的确定AMR-WB采样频率为16kHz，AMR的采用频率为8kHZ。
AMR-WB总共支持8种模式，其中模式2代表AMR-WB 12.65kbps，模式8代表AMR-WB 23.85kbps。
在上图中就是mode-set=2，表示AMR-WB只适应12.65kbps编码方式。
VOLTE呼叫过程中，I NVITE消息中携带的媒体类型和编码格式：主被叫协商以后，在UPDATE消息中确定的媒体类型和编码格式：AMR-WB采样频率为16kHz，AMR的采用频率为8kHZ。
AMR-WB总共支持8种模式，其中模式2代表AMR-WB 12.65kbps，模式8代表AMR-WB 23.85kbps。
在上图中就是mode-set=2，表示AMR-WB只适应12.65kbps编码方式。
建立语音业务承载QCI=1，打开ROHCTTI-Bundling关闭关闭SPS功能，通过查看qci=1语音承载RRCConnectionReconfiguration消息，没有sps 相关ie。
四、Volte呼叫vollte的AMR-WB 23.85k的确定：1：Invite消息中的AMR-23.85k的编码方法：2：update 消息中协商以后的媒体类型和编码方式。
下图中：媒体类型为AMR-WB，采样频率为16k，单通道。
采用的模式为AMR-WB的mode 8。
mode8对应的编码速率为23.85kbps。
五、VoL TE呼叫2G上图是VoLTE呼叫2G信令流程。
流程和VoLTE呼叫VoLTE是相同的。
IMS呼叫流程
网管层 M2000 i2000 N2000BMS
绿色呼叫 业务层 SIP SCP 核心层 MRS
V网伴侣
统一Centrex
SIP
SIP MGCF BICC GSM
I/S-CSCF
P-CSCF
接入层
SBC GPON
SBC GPON
十一个地市 ..........
SBC GPON
杭州
2 INVITE
中国移动IP专网 中国移动
宁波
SBC
宁波
信令流 媒体流
GMGW OLT
1 INVITE
宁波城域网
/IP专网
• 该会话场景适用于各地市IMS 用户呼叫其他地市（也包括本地 市）2G用户的呼叫过程。 • 位于省中心机房的MGCF将与 各地市GMSC SERVER之间使用 BICC协议互联。 •数据配置需求： 当MGCF发现 是移动号码时， 需要进行分析， 如果是本省的移动号码， 则 MGCF需要分析出是属于哪个地 市的号码， 直接将呼叫路由到该 地市。 对于省外号码，则路由到 主叫上来的地市的GMSC Server。 由该GMSC Server再 通过T1 路由到省外。这种方式比 较迂回。 可选方案是通过杭州 GMSC Server路由到T1局， 减 少了迂回，但是会对杭州GMSC Server造成加大压力。
2 INVITE
10 INVITE
中国移动IP专网 中国移动
宁波
SBC
温州
信令流 媒体流
SBC
1 INVITE
11 INVITE
OLT
宁波城域网
/IP专网
温州城域网 /IP专网
OLT
主叫IMS用户
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
VoLTE呼叫Invite流程详解
VoLTE呼叫Invite流程详解
以VoLTE-to-VoLTE信令为例，分析IMS用户之间的基本会话的Invite过程。
IMS用户之间的基本会话Invite过程（TEL URI）
呼叫处理流程如下：
1、主叫（IMPI）+86158********@呼叫被叫（IMPI）
+86158********@的tel号码（TEL URI）tel:+86158********；
2、首先经过主叫的P-CSCF和S-CSCF，S-CSCF到ENUM中查询SIP标识（SIP URI），查询结
果为sip:+86158********@；
3、将被叫SIP标识（SIP URI）sip:+86158********@ 再到DNS解析，解析出I-CSCF的IP地址；
4、然后I-CSCF到HSS查询，并携带被叫SIP标识（SIP URI）
sip:+86158********@zj.ims.mnc000.mcc460.3gppnetwork.or g，HSS检查是否该用户的该IMPU已经注册，如果没有注册HSS将返回用户不存在。
5、如果注册了，就将该用户注册所在的S-CSCF的hostname返回给I-CSCF，从而使得I-CSCF
可以找到S-CSCF，因为该用户已经注册了，也就是已经存在该IMPU与IP地址的绑定关系，根据sip:+86158********@查找绑定关系，返回被叫UE注册的IP地址。
6、最后将绑定关系发给被叫P-CSCF，被叫P-CSCF根据IP地址找到被叫，完成IMS域中两
个TEL号码之间的互通。
voip技术原理及呼叫流程
ＶｏＩＰ是建立在ＩＰ技术上的分组化、数字化传输技术，其基本原理是：通过语音压缩算法对语音数据进行压缩编码处理，然后把这些语音数据按ＩＰ等相关协议进行打包，经过ＩＰ网络把数据包传输到接收地，再把这些语音数据包串起来，经过解码解压处理后，恢复成原来的语音信号，从而达到由ＩＰ网络传送语音的目的。
ＩＰ电话系统把普通电话的模拟信号转换成计算机可联入因特网传送的ＩＰ数据包，同时也将收到的ＩＰ数据包转换成声音的模拟电信号。
经过ＩＰ电话系统的转换及压缩处理，每个普通电话传输速率约占用８～１１ｋｂｉｔ／ｓ带宽，因此在与普通电信网同样使用传输速率为６４ｋｂｉｔ／ｓ的带宽时，ＩＰ电话数是原来的５～８倍。
ＶｏＩＰ的核心与关键设备是ＩＰ电话网关。
ＩＰ电话网关具有路由管理功能，它把各地区电话区号映射为相应的地区网关ＩＰ地址。
这些信息存放在一个数据库中，有关处理软件完成呼叫处理、数字语音打包、路由管理等功能。
在用户拨打ＩＰ电话时，ＩＰ电话网关根据电话区号数据库资料，确定相应网关的ＩＰ地址，并将此ＩＰ地址加入ＩＰ数据包中，同时选择最佳路由，以减少传输时延，ＩＰ数据包经因特网到达目的地ＩＰ电话网关。
对于因特网未延伸到或暂时未设立网关的地区，可设置路由，由最近的网关通过长途电话网转接，实现通信业务。
目前ＶｏＩＰ系统一般由ＩＰ电话终端、网关（Ｇａｔｅｗａｙ）、网（关）守（Ｇａｔｅｋｅｅｐｅｒ）、网管系统、计费系统等几部分组成。
ＩＰ电话终端包括传统的语音电话机、ＰＣ、ＩＰ电话机，也可以是集语音、数据和图象于一体的多媒体业务终端。
由于不同种类的终端产生的数据源结构是不同的，要在同一个网络上传输，这就要由网关或者是通过一个适配器进行数据转换，形成统一的ＩＰ数据包。
ＩＰ电话网关提供ＩＰ网络和电话网之间的接口，用户通过ＰＳＴＮ本地环路连接到ＩＰ网络的网关，网关负责把模拟信号转换为数字信号并压缩打包，成为可以在因特网上传输的ＩＰ分组语音信号，然后通过因特网传送到被叫用户的网关端，由被叫端的网关对ＩＰ数据包进行解包、解压和解码，还原为可被识别的模拟语音信号，再通过ＰＳＴＮ传到被叫方的终端。
移动通信基本呼叫流程
移动通信基本呼叫流程移动通信基本呼叫流程1.简介本文档旨在介绍移动通信基本呼叫流程，包括信令流程、数据传输流程以及附加功能。
通过详细描述呼叫的发起、连接、传输和结束过程，读者能够了解移动通信系统中呼叫的基本工作原理。
2.信令流程2.1 建立呼叫首先，呼叫方发送请求建立呼叫的信令给移动通信系统。
移动通信系统通过寻址和鉴权等步骤确认呼叫方的身份，并为该呼叫分配资源。
接下来，移动通信系统通知被叫方有一个呼叫请求。
被叫方可以选择接受或拒绝该呼叫。
2.2 呼叫连接如果被叫方接受呼叫，移动通信系统会建立呼叫连接，包括建立信道连接和配置一系列参数等步骤。
一旦呼叫连接建立，呼叫方和被叫方之间可以进行语音通话或数据传输。
2.3 通话中在呼叫连接建立后，呼叫方和被叫方可以进行通话。
移动通信系统负责信号处理、数据交换和其他必要的功能。
通话过程中，系统会持续监测信号质量，以保证通话质量。
2.4 呼叫释放当呼叫结束时，呼叫方和被叫方可以通过发送释放信令来终止呼叫。
移动通信系统会释放相关资源，并记录呼叫相关信息。
3.数据传输流程3.1 数据传输准备在进行数据传输之前，移动通信系统需要进行一系列准备工作。
这包括配置数据通道、分配IP地质等。
系统还会对数据进行压缩和加密等处理。
3.2 数据传输一旦数据传输准备完成，移动通信系统可以开始传输数据。
数据可以是文本、图片、音频或视频等。
系统会负责数据的分割、传输和重组等操作。
3.3 数据接收被叫方会接收到传输的数据，并进行相应的处理。
系统会负责数据的解码、解压缩等操作。
被叫方可以选择展示数据或进行进一步处理。
4.附加功能4.1 呼叫转移移动通信系统支持呼叫转移功能。
用户可以将呼叫转移到其他设备或号码，以实现流动性。
4.2 呼叫等待当用户正在通话中时，如果有其他呼叫进来，移动通信系统可以提供呼叫等待功能。
用户可以选择接听新的呼叫或忽略它。
4.3 呼叫保持在通话中，用户可以选择将当前的呼叫保持起来，以便进行其他操作。
VoLTE主叫信令流程详解
VoLTE主叫信令流程详解（有抓包截图详细介绍）：注册的目的是信息登记，并为后续的主被叫提前进行了相应的寻址。
例如，主叫流程中信令所经历的网元路径就是在注册阶段被分配好的，并在该UE注册期间保持不变。
IMS域的的主叫信令流程总览如下：1、首先UE向P-CSCF发出SIP INVITE请求，包含初始SDP消息，该初始SDP消息包含一个多媒体会话的一个或多个媒体流。
UE需要在INVITE消息了嵌入Accept:application/sdp,application/3gpp-ims+xml，这里主要指明了MIME(MultipurposeInternet Mail Extensions)的业务格式类型（例如XML、HTML 或者还是WMV等业务媒体格式），以便被服务器进行正确的解码处理，这一点在计算机应用中很普遍，如果没有注明正确的类型，后果很难评估；P-Early-Media: supported，支持该消息意味着支持主叫早放，例如，当收到180振铃指示，UE按授权进行相应的媒体播放；P-Preferred-Identity:sip:+86134***************,这里提供了用户的公共标识，与后续从S-CSCF传来的P-Asserted-Identity保持一致；P-Preferred-Service:urn:urn-7:3gpp-service.ims.icsi.mmtel, IMS Communication Service Identifier(ICSI),IMS通信服务标识符在UE与网络侧标记着应用。
UE通过该标识符分发SIP 消息到正确的应用，而网络侧通过该标识选择正确的应用服务器；a: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel",媒体类型标签，标识着终端可支持的软件应用，同时也表征着终端的能力(例如该终端是个电话或者是PDA)；在初始SIP请求中包含的SDP消息应严格符合RFC 4566中定义的SDP协议格式，包含不同域的排列顺序、以及域中内容的格式要求。
IMS注册呼叫信令流程详解
IMS注册呼叫信令流程详解
1.IMS注册过程：
-移动设备启动时，会向IMS注册服务发送注册请求。
该请求包含设备的标识信息和网络接入类型等。
-IMS注册服务收到注册请求后，会验证设备的合法性，并且分配一个唯一的标识号码给该设备。
-设备收到来自IMS注册服务的确认消息后，将得到的标识号码保存为设备的IMS私有标识。
2.呼叫设置过程：
-主叫设备向IMS呼叫服务发送呼叫请求。
该请求包含被叫设备的标识号码和呼叫类型等。
-IMS呼叫服务根据被叫设备的标识号码找到对应的位置信息，并将呼叫请求发送给被叫设备。
-被叫设备收到呼叫请求后，可以选择接受或拒绝该呼叫请求。
如果接受请求，被叫设备会回复一个确认消息给IMS呼叫服务。
-IMS呼叫服务收到被叫设备的确认消息后，会将呼叫的相关信息传递给主叫设备，并向主叫设备发送呼叫确认消息。
3.呼叫释放过程：
-当呼叫结束时，主叫设备会向IMS呼叫服务发送呼叫释放请求。
-IMS呼叫服务收到释放请求后，会向被叫设备发送释放消息。
-被叫设备收到释放消息后，向IMS呼叫服务发送释放确认消息。
-IMS呼叫服务收到释放确认消息后，将呼叫释放的相关信息传递给
主叫设备，并向主叫设备发送释放确认消息。
总结起来，IMS注册呼叫信令流程包括注册过程、呼叫设置过程和呼
叫释放过程。
通过这些过程，移动设备可以在IMS网络上实现多媒体通信，包括语音、视频、短信和数据传输等。
这些信令过程保证了设备之间的顺
畅通信，使人们能够享受高质量的多媒体通信服务。
ims呼叫流程
ims呼叫流程IMS呼叫流程。
IMS（IP Multimedia Subsystem）是一种基于IP网络的多媒体子系统，它为各种多媒体服务提供了统一的架构和接口。
在IMS中，呼叫流程是其中一个重要的组成部分，它涉及到用户设备、IMS核心网络和其他相关网络实体之间的通信和交互。
本文将详细介绍IMS呼叫流程的相关内容。
首先，当用户A拨打用户B的电话时，呼叫流程开始。
用户A的设备首先会向其所在的IMS核心网络发送呼叫请求，IMS核心网络会对呼叫请求进行处理，并根据用户B的位置信息将呼叫请求转发给用户B所在的网络。
接着，用户B的设备会接收到呼叫请求，并向IMS核心网络发送响应消息，确认是否接受呼叫。
IMS核心网络会将用户B的响应消息转发给用户A的设备，从而完成呼叫的建立。
在呼叫建立之后，用户A和用户B之间可以进行语音通话、视频通话或其他多媒体通信。
当通话结束时，用户A或用户B可以发起挂断操作，IMS核心网络会收到挂断请求，并进行相应的处理，最终结束通话。
需要注意的是，在整个呼叫流程中，IMS核心网络扮演着关键的角色，它负责呼叫请求的处理、转发和通话的管理。
同时，IMS核心网络还需要与其他相关网络实体进行交互，以实现用户设备之间的通信。
除了上述的基本呼叫流程，IMS还支持一些高级的功能，如呼叫转移、呼叫等待、多方通话等。
这些功能在实际的通信场景中都有着重要的作用，它们丰富了通信的方式和方式，提高了用户的通信体验。
总的来说，IMS呼叫流程是一个复杂而又精密的系统，它涉及到多个实体之间的协作和交互，以实现用户设备之间的通信。
通过本文的介绍，相信读者对IMS呼叫流程有了更加全面和深入的了解，这对于理解和应用IMS技术都具有着重要的意义。
希望本文能够对您有所帮助，谢谢阅读！。
IMS注册及业务基本流程
IMS注册及业务基本流程
3.分配注册资料：IMS注册服务器为成功验证的用户分配注册资料，
包括用户所属的服务域、呼叫功能设置和多媒体会话支持。
4.通知用户注册成功：IMS注册服务器向用户设备发送注册成功消息，包括唯一的IMS用户标识和注册资料。
用户设备接收到注册成功消息后，
保存注册相关信息以备后续使用。
5.定期更新注册状态：注册成功后，用户设备会定期更新自己的注册
状态，向IMS注册服务器发送心跳消息以维持注册有效性。
IMS业务基本流程：
2.IMS服务域路由呼叫请求：IMS服务域接收到呼叫请求后，根据呼
叫路由策略找到目标用户所在的服务域，将呼叫请求转发给目标用户所在
的IMS注册服务器。
3.目标IMS注册服务器处理呼叫请求：目标IMS注册服务器接收到呼
叫请求后，根据呼叫路由策略找到目标用户所在的终端设备，并将呼叫请
求发送给目标用户设备。
4.目标用户设备接听呼叫：目标用户设备接收到呼叫请求后，展示相
应的来电信息，并提供接听或拒绝呼叫的选项。
如果用户选择接听呼叫，
终端设备会建立通话连接。
5.通话中传输媒体数据：通话建立后，终端设备之间通过IP网络传
输语音或视频等媒体数据。
6.结束通话：通话结束后，用户可以选择挂断通话。
终端设备发送相
应的挂断通知给目标用户设备，并关闭通话连接。
以上是IMS注册及业务的基本流程。
通过IMS系统，用户可以方便、
快捷地进行多媒体业务通信，实现语音、视频和消息等多样化的通信需求。
IMS系统的出现使得多媒体通信更加高效、便捷，为用户创造了更好的通
信体验。
IMS注册呼叫信令流程详解
SIP协议消息的分类
SIP消息采用文本方式编码，分为两类：请求消息和响应消息。 请求消息和响应消息都包括SIP头字段和SIP消息字段。 请求消息和响应消
息在形式上的区别仅在消息的第一行，请求的第一行为请求行，响应的第 一行为状态行。
SIP请求消息
请求消息：客户端为了激活按特定操作而发给服务器的SIP消息。 RFC3261定 义了六个基本方法，包括INVITE，ACK, OPTIONS, BYE, CANCEL, REGISTER。后续 RFC扩展了其他的请求方法，如UPDATA，INFO，SUBSCRIBER，NOTIFY， MESSAGE，PRACK，REFER。
• (3)183(根据最顶端Via头找到Ｐ, 将 • Record-Route消息头中带回)
• (５)PRACK(将Record-Route消息头 颠倒
• 顺序，变换成Route消息头，后续 请求
• 路由根据一系列的Route消息头路 由)
• （6）PRACK
SIP消息中的头域
Service-Route:由S-CSCF设置，在REGISTER请求的200（OK）响应中将S-CSCF 的IP地址通过该消息头返回给P-CSCF，在后续的会话过程中， P-CSCF通过该 消息头找到S-CSCF。 如：Service-Route:<sip:SCSCF1.home.fr>;lr
会话描述协议SDP（Session Description Protocol）协议为应用层的控制 协议,用于SIP会话建立过程中的媒体协商过程。
RTP/RTCP：都为应用层的承载面协议，SIP会话建立后，RTP协议保证媒体 流的实时传输。RTCP协议对实时传输的媒体流进行监控。
目录
ims呼叫流程
ims呼叫流程IMS呼叫流程。
IMS（IP Multimedia Subsystem）是一种基于IP网络的多媒体通信系统，它为多种服务提供了统一的访问和交付平台。
在IMS中，呼叫流程是非常重要的一部分，它涉及到用户与网络之间的交互，以及网络内部各个功能模块之间的通信。
下面将详细介绍IMS呼叫流程的相关内容。
首先，当用户发起呼叫时，终端设备会向IMS网络发送呼叫请求。
这个呼叫请求会经过无线接入网和核心网，最终到达IMS核心网络。
在核心网中，呼叫请求会被路由到相应的呼叫控制功能（Call Session Control Function，CSCF）节点上。
接下来，CSCF节点会对呼叫请求进行处理，包括鉴权、用户状态查询等操作。
如果用户合法且可用，CSCF节点会向用户发送呼叫响应，表示呼叫请求已经被接受。
同时，CSCF节点会向相应的应用服务器发送呼叫请求，以便应用服务器进行呼叫处理。
在得到应用服务器的处理结果后，CSCF节点会向用户发送呼叫响应，告知用户呼叫处理的结果。
如果呼叫成功，用户可以与被叫用户进行通话；如果呼叫失败，用户会收到相应的失败提示。
在通话过程中，IMS网络会对通话进行监控和管理，以保证通话质量和用户体验。
一旦通话结束，终端设备会向IMS网络发送通话释放请求，IMS网络会对通话进行清理和释放。
除了上述的基本呼叫流程外，IMS还支持一些高级的呼叫功能，比如呼叫转移、呼叫等待、多方通话等。
这些功能都是基于IMS网络的强大能力和灵活性而实现的，为用户提供了丰富多彩的通信体验。
总的来说，IMS呼叫流程是一个复杂而又精密的系统工程，它涉及到多个网络节点和功能模块之间的协作与交互。
通过上述的介绍，相信大家对IMS呼叫流程有了更深入的了解。
希望本文能够帮助大家更好地理解IMS网络，并为相关领域的研究和实践提供一定的参考价值。
移动通信基本呼叫流程
移动通信基本呼叫流程移动通信基本呼叫流程⒈引言移动通信基本呼叫流程是指当用户发起呼叫时，从呼叫开始到结束的整个过程。
本文档将详细介绍移动通信基本呼叫流程的各个阶段和步骤。
⒉呼叫前准备⑴确定呼叫类型：在发起呼叫前，用户需确定呼叫的类型，包括语音呼叫、短信呼叫或数据呼叫。
⑵选择通信方式：用户需选择合适的通信方式，包括蜂窝网络通信、无线局域网通信或卫星通信等。
⑶确定通信对象：用户需确定要拨打的号码或选择通讯录中的联系人。
⒊建立连接⑴寻呼和寻址：通信系统将尝试在网络中寻找被呼叫方，并确定其位置。
⑵呼叫请求：主叫方通过网络向被呼叫方发起呼叫请求，包括发起方的标识和呼叫类型等信息。
⑶呼叫建立：被呼叫方接收到呼叫请求后，如果接受呼叫，则建立连接并通知主叫方。
⒋通话过程⑴语音传输：在连接建立后，双方可以进行实时语音传输，并通过手持设备进行通话。
⑵数据传输：如果呼叫类型为数据呼叫，通信系统将确保数据的传输和接收，并进行必要的错误检测和纠正。
⒌呼叫结束⑴结束通话：通话结束时，双方可通过手持设备结束通话，并释放连接资源。
⑵通话费用计算：通话结束后，通信系统将根据通话时长和费率计算通话费用，并进行账单。
⒍附件本文档涉及的附件包括：- 通信系统架构图- 呼叫流程示意图⒎法律名词及注释- 通信系统：指提供移动通信服务的基础设施和技术平台。
- 主叫方：指发起呼叫的用户。
- 被呼叫方：指接收呼叫的用户。
- 呼叫类型：指呼叫的种类，包括语音呼叫、短信呼叫或数据呼叫等。
- 通信方式：指用户使用的通信技术和网络类型。
- 寻呼和寻址：通信系统根据被呼叫方的标识信息确定其位置。
- 呼叫请求：指主叫方通过网络向被呼叫方发起的呼叫请求，并包括发起方的标识和呼叫类型等信息。
- 通话费用计算：通信系统根据通话时长和费率计算通话费用，并进行账单。
IMS主要协议和典型流程
IMS主要协议和典型流程
SIP是一种应用层协议，用于建立、修改和断开多媒体会话，它是
IMS中最核心的协议之一、其典型的流程包括：
1. 注册流程：用户在终端设备上输入自己的账号和密码，终端设备
通过SIP协议向Home Subscriber Server（HSS）发送注册请求，HSS验
证用户的身份，并返回注册成功的消息给用户终端设备。
2. 会话建立流程：用户A通过终端设备向用户B发送一个通话请求，用户B通过终端设备接收到请求后，可以选择接受或者拒绝。
如果用户B
接受请求，B的终端设备通过SIP协议向B的Proxy-Call Session
Control Function（P-CSCF）发送一个呼叫请求，P-CSCF根据B的位置
信息在服务域内查找用户B对应的S-CSCF，S-CSCF负责处理B的呼叫请求，最终将请求发送给B。
3.呼叫传输流程：一旦用户B接受请求，通话的数据就可以通过SIP
协议进行传输。
通话数据经过用户终端设备、P-CSCF、S-CSCF等网络设备，最终到达用户的终端设备。
在通话过程中，用户可以进行多种操作，
如静音、挂断等。
4.会话结束流程：一方挂断通话后，终端设备通过SIP协议向对方发
送一个结束通话的消息，对方通过终端设备接收到消息后，也会发送一个
结束通话的消息给对方。
双方的终端设备接收到对方的结束通话消息后，
会结束通话。
总的来说，IMS的主要协议是SIP，它通过注册、会话建立、呼叫传
输和会话结束等流程实现多媒体通信。
通过IMS，用户可以使用终端设备
进行语音、视频、数据等多种类型的通信，实现了多媒体通信的统一和标准化。
IMS试点基本注册呼叫信令流程概论
请求消息
消息含义
INVITE ACK BYE CANCEL
REGISTER OPTIONS
发起会话请求，邀请用户加入一个会话，会话描述含于消息体中 证实已收到对于INVITE请求的最终响应。该消息仅和INVITE消息配套使用 结束会话 取消尚未完成的请求，对于已完成的请求（即已收到最终响应的请求）则 没有影响 用于在IMS中注册，完成地址绑定 查询对端能力或状态
归属域和漫游域
归属域：就是用户的签约数据所在的运营商。 漫游域：就是从归属域之外的其他运营商接入，这个其他运营商统称为
漫游域。
IMS网络中，用户无论在归属域还是漫游域，其注册流程是相同的
路漫漫其悠远
注册流程相关概念－鉴权
鉴权
鉴权，即认证，是识别某实体或用户的身份，并确保该实体或用户为合 法用户身份的方法。
请求中的首行格式包括方法、请求的URI、协议版本。 例如： INVITE sip:bob.smith@ SIP/2.0 REGISTER sip:home1.fr SIP/2.0
响应中的首行格式包括版本、状态码以及原因短语。 例如： SIP/2.0 100 Trying SIP/2.0 183 Session in Progress SIP/2.0 200 OK
开户时在HSS中配置并储存，注册成功后下发到SCSCF。
Service Profile
闭锁设置 注册设置 漫游设置
。。。
iFC1 iFC2 iFC3 iFC n
该用户向哪个（些）AS 注册
该用户做主叫时触发哪 个（些）AS
该用户做被叫时触发哪 个（些）AS
注册涉及的基本概念－隐式注册、第三方注册
Max-Forwards：消息的剩余跳数 如 Max-Forwards：70
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SGW/ PGW
eNB
1）INVITE
to
B
2）100
Trying
3）INVITE
to
B
4）100
Trying
5）180
Ringing
ห้องสมุดไป่ตู้
6）PRACK
of
AS
7）180
Ringing
页面布局参考
1. Parlay网关（Parlay GW）
+ Parlay网关是整个系统的核心设备，负责提供协议适配和业务能力集，采用CORBA 体系结构构建。对外提供标准开发接口Parlay API，供第三方进行业务开发。
2. 应用服务器
应用服务器负责运行各种业务，SoftDA业务的业务逻辑运行在应用服务器上， 应用服务器和Parlay网关之间采用Parlay API协议。
+ 用于提供Web服务，供系统管理员和个人用户对SoftDA业务进行Web管理。 系统管理员可以进行用户管理等操作，包括用户的创建﹑用户属性修改或用 户删除等。SoftDA用户可以登录Web服务页面，对自己的业务属性进行自助 管理，包括电话号码﹑使用语音等的管理。
5．PS服务器
PS服务器实现在线服务器功能，通过xmpp协议和客户端通讯，PS服务器实 现了用户在线和电话在线的功能，电话在线信息由数字助理应用提供。
页面布局参考
SoftDA业务是一个集成各种子业务功 能而来的统一的通信平台。其涉及到 的设备除了Parlay网关，应用服务器， 媒体服务器之外，还包括短消息网关， PS服务器，E-Mail服务器。
用户呈现，查看在线好友状态等功能， 通过PS服务器来实现，即时消息功 能也通过PS服务器实现，发送和接 收短消息通过和短消息网关通信来实 现，发送和接收E-Mail通过和邮件服 务器通信来实现 。
eNB
1）INVITE to B 2）100 Trying
3）INVITE to B 4）100 Trying
5）180 Ringing 6）PRACK of AS
7）180 Ringing 8）PRACK of A 9）200 OK of AS to A
10）200 OK of B 11）200 OK of B with SDP
12）ACK
13）PUBLISH of B 14）200 OK to B
15）200 OK to A with SDP for B 16）ACK of A
17）Notify 18）200 OK of A
19）PUBLISH of A 20）200 OK of A
21）Notify 22）200 OK of B
+ 1、IMS 网络结构 + 2、softda网络结构 + 3、LTE系统组网 + 4、SIP呼叫流程 + 5、常见LTE业务呼叫流程
+ 1．业务应用服务器 提供如下IMS业务及管理，包括即时消息服务器（Message APP)、状态呈现服务器 （Presence APP）、群组管理（Group Management）、多媒体彩铃/彩铃应用服务器 （MRBT/CRBT APP）、彩像应用服务器（MMCI APP）、T120服务器（电子白板、应用共 享）、Parlay网关应用服务器（ParlayGW APP）、综合VPN应用服务器（VPN APP）等。
页面布局参考
UTRAN
E-UTRAN
GERAN S12
S3 EPC
SGSN
ZXUP10统一业务开放平台
X1
X2 UE
S1-Mme
S6a
Mme S11
Gi
SCP/SMP/ SDB合一
X1 eNB
UE
S1-U
S5/S8a
S-GW
P-GW
SMS（包括SMP、SMAP）负责对智能网及智能 网业务进行管理。它包括对业务的管理、对业务 用户的管理、对网络的管理、对业务管理接入和
包括SIP IAD、DSLAM、AG、ADSL调制器、SBC边界控制器、防火墙服务器等设备， 其中，AG/SIP IAD设备用于酒店场景的传统固网PSTN终端的接入设备，为了向这些终 端提供基于IMS网络下的IP CENTREX业务，需要将传统PSTN终端通过AG/SIP IAD接入到 IMS Core中的AGCF。 + 7．终端: 包括手机、PDA、SIP PHONE、SIP IAD、PC终端等设备。
理。功能包括放音服务器、交互式话音响应（IVR/VRU）、会议桥接、信息设备和话音 平台等功能。 + 4．IMS核心网设备
包括IMS会话CSCF（P/I/S-CSCF）、HSS用户数据库，用于和CS/PSTN网络互通的 MGCF/IM-MGW，固网接入的AGCF。 + 5．IP承载网络设备: 用于实现IP组网。 + 6．接入网络设备
系统接入的管理等功能。
SGi S7
Rx+
PCRF
SCP在整个智能网系统中起着控制和处理智能业 务的作用，它完成业务控制功能(SCF)和业务数据 功能(SDF)，同时接受SMS对它的管理。
AS服务器 Smap
Gi Internet
单机环境下的简单组网
AS服务器
AS给用户A 播放回铃音
SGW/ PGW
3. 媒体服务器
媒体服务器是在IP网络环境下提供专用媒体资源功能的独立设备，是NGN网 络中的重要设备，提供增值业务中的媒体处理功能，包括DTMF信号的采集 与解码、信号音的产生与发送、录音通知的发送、会议、不同编解码算法间 的转换等各种资源功能以及通信功能和管理维护功能。
页面布局参考
4. Web服务器
23）BYE of A 24）200 OK (for BYE of A)
25）BYE (to B) 26）200 OK(for BYE of B)
Caller A
Callee B
主叫用户A 发起呼叫B
被叫用户 B振铃
被叫用户 B摘机
A Talking with B 主叫用户挂机
AS服务器
AS给用户A 播放回铃音
+ 2．多媒体会议服务器 可以向IMS网络用户提供多媒体视频会议业务，除了服务于IMS终端用户外，还可支持 H.323用户，采用中兴全兼容智能视讯服务器ZXMVC8900，全面支持IMS SIP ，H.323、 H.320等协议，可通过IMS网络为多种接入网络用户提供多媒体会议业务。
+ 3．媒体服务器MRS 负责为IMS业务（如SoftDA/彩铃/多媒体彩铃/彩像等业务）提供媒体资源的相关处