3GPP2 X.S0013-009-0
Version: 1.0
Date: December 2007
IMS/MMD Call Flow Examples
COPYRIGHT
3GPP2 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@https://www.doczj.com/doc/181414040.html,. Requests to reproduce individual Organizational Partner’s documents should be directed to that Organizational Partner. See https://www.doczj.com/doc/181414040.html, for more information.
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples Revision History
Revision Changes Date v1.0 Initial Publication December, 2007
IMS/MMD Call Flow Examples
1
CONTENTS
2
3
Revision History ii 4
1Introduction 4 2Glossary and Definitions 5 5
6
2.1Acronyms 5 7
2.2Definitions 5
3References 6 8
9
3.1Normative References 6 10
3.2Informative References 6
4Methodology 7
11
12
4.1Functional Entities covered by call flows 7 13
4.2Identities 7 14
4.2.1User and Network Identities (7)
15
4.3Notation for call flows 8 16
5Registration Procedures 8 6Signaling flows for session establishment 9
17
18
6.1General assumptions 9 19
6.2Scenarios 9
6.2.1Scenario 1 (9)
20
21
6.2.1.1Assumptions (10)
22
6.2.1.2Call Flow (10)
6.2.2Scenario 2 (15)
23
6.2.2.1Assumptions (15)
24
6.2.2.2Call Flow (15)
25
6.2.3Scenario 3 (16)
26
6.2.3.1Assumptions (16)
27
28
6.2.3.2Call flow (16)
29
6.2.4Scenario 4 (23)
30
6.2.4.1Assumptions (23)
31
6.2.4.2Call flow (23)
32
Appendix A (Informative): VoIP example with QoS reservation, activation, and updating at RAN 31
A.1QoS Configuration for VoIP in advance 31
33
A.2Resource activation on originating side 33
34
A.3Resource activation on terminating side 34
35
1
A.4Updating of resource reservation 35 2
A.4.1Resource updating on originating side 35
A.4.2Resource updating on terminating side 37 3
4
LIST OF FIGURES
1
Figure 1 Originating UE resource ready, terminating UE resource ready (10)
2
3
Figure 2 Originating UE resource ready, terminating UE resource not ready (15)
4
Figure 3 Originating UE not ready, Terminating UE ready (17)
5
Figure 4 Originating UE not ready, Terminating UE not ready (24)
6
Figure 5 QoS configuration for VoIP (32)
Figure 6 QoS Activation on Originating UE (33)
7
8
Figure 7 QoS Activation on Terminating UE (34)
9
Figure 8 Resource Updating on Originating UE (36)
Figure 9 Resource Updating on Terminating UE (37)
10
11
1 Introduction
1
2
The document provides examples of signaling flows for the IP multimedia call control based on 3
SIP 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. 4
5
The call flows describe the behavior of the mobile stations under various conditions for setting up 6
real time services like VoIP and PSVT.
7
In 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 9
Engineering Style Manual.
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples
2 Glossary and Definitions
1
2.1 Acronyms
2 AAA Authentication, Authorization, and Accounting
3
AN 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 Subsystem
9 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 Network
19 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 IP
27 2.2 Definitions
28 Caller
The person placing a call
29 Called party The recipient or destination of a call
30 Alert
The audible notification given to the Called party of an incoming call. 31 Ring Back
The audible notification given to a Caller to indicate that the Called 32 party has been located and is being alerted
33
3 References
1
2
The following documents contain provisions, which, through reference in this text, constitute 3
provisions of this document.
4
References are either specific (identified by date of publication, edition number, version 5
number, etc.) or non-specific.
6
For a specific reference, subsequent revisions do not apply.
7
For a non-specific reference, the latest version applies. In the case of a reference to a 8
3GPP2 document, a non-specific reference implicitly refers to the latest version of that 9
document in the same Release as the present document.
References
3.1 Normative
10
11
[1]3GPP2 X.S0013-004-A v1.0: “IP Multimedia Call Control Protocol Based on SIP and SDP 12
Stage 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 Video
15
(H.263+)”.
16
[4]IETF RFC 3558, “RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and 17
Selectable Mode Vocoders (SMV)”.
18
[5]IETF RFC 3262, “Reliability of provisional Responses in the Session Initiation Protocol
(SIP)”
19
20
[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 22
Subsystem Cx Interface Signaling flows and Message Contents” – Annex A.
23
References
3.2 Informative
24
25
26
[8] 3GPP2 X.S0013-012-0 v1.0: “All-IP Core Network Multimedia Domain; Service Based 27
Bearer Control – Stage 2”.
28
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples
4 Methodology
1
4.1 Functional Entities covered by call flows
2
3
The flows show the signaling exchanges between the following functional entities:
4
5
User Equipment (UE)
6
Proxy-CSCF (P-CSCF)
7
Interrogating-CSCF (I-CSCF)
8
Serving-CSCF (S-CSCF)
9
10
The call flows mainly show the interactions between the UE-1 and UE-2 for call origination and 11
termination. The procedures and the message exchanged between these elements are as described in [1].
12
4.2 Identities
13
4.2.1 User and Network Identities
14
15
The public identity of UE-1 is sip:UE-1@https://www.doczj.com/doc/181414040.html,. The public identity of UE-2 is
sip:UE-2@https://www.doczj.com/doc/181414040.html,
16
17
18
The following are network entities associated with UE-1:
19
20
Home Domain of UE-1: https://www.doczj.com/doc/181414040.html,
21
P-CSCF serving UE-1: https://www.doczj.com/doc/181414040.html,
22
I-CSCF serving UE-1: https://www.doczj.com/doc/181414040.html,
23
S-CSCF serving UE-1: https://www.doczj.com/doc/181414040.html,
24
The following are the network entities associated with UE-2:
25
26
Home Domain of UE-2: https://www.doczj.com/doc/181414040.html,
27
P-CSCF serving UE-2: https://www.doczj.com/doc/181414040.html,
28
I-CSCF serving UE-2: https://www.doczj.com/doc/181414040.html,
29
S-CSCF serving UE-2: https://www.doczj.com/doc/181414040.html,
30
31
In the example session establishment flows, both UE-1 and UE-2 are assumed to be in the home 32
network. So, the P-CSCF1 and P-CSCF2 are in UE-1’s and UE-2’s respective home networks.
33
However, according to [2], the P-CSCF can be either in the home or visited network. The session 34
establishment call flows described in this document are not affected whether the P-CSCF is in the 35
visited or home network.
36
For brevity, I-CSCF and S-CSCF are shown together in the session establishment call flows.
4.3 Notation for call flows
1
2
Offer/Answer exchange process is also shown in the call flows. For brevity, the following notation is used to 3
represent 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 6
setup 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”.
8
9
10
11
Procedures
5 Registration
12
13
The registration procedures for UE-1 and UE-2 are as specified in [1] and [7]. UE-1 registers with 14
S-CSCF1 through P-CSCF1 and UE-2 registers with S-CSCF2 through P-CSCF2.
15
16
17
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples
1 6 Signaling flows for session establishment
2 In all of the call flows provided in this document, registration procedures are assumed to have already been
3 completed. 4
5 6.1 General assumptions
6
All the call flows shown in this document assume the following:
7 ? The originating UE and the terminating UE both support precondition and reliable provisional responses
8 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 are
11 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 for
15 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 decides
18 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) response
21 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 a
23 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 an
27 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. 30
31 6.2 Scenarios
32 The following scenarios are considered for the session establishment process:
33 ? Scenario 1: Originating UE has resources ready before sending INVITE, terminating UE has resources
34 ready before sending the first provisional response;
35 ? Scenario 2: Originating UE has resources ready before sending INVITE, terminating UE does not have
36 resources ready before sending the first provisional response;
37 ? Scenario 3: Originating UE does not have resources ready before sending INVITE, terminating UE has
38 resources ready before sending the first provisional response;
39 ? Scenario 4: Originating UE does not have resources ready before sending INVITE, terminating UE does
40 not have resources ready before sending the first provisional response.
41
42 The call flows for the above four scenarios are depicted in the subsequent subsections.
43 6.2.1 Scenario 1
44 This section covers the scenario where the originating UE’s resources are ready before sending INVITE, and the
45
terminating UE’s resources are ready before sending the first provisional response.
1
2
6.2.1.1 Assumptions
3
Flow
6.2.1.2 Call
4
5
The following section applies to the case where UE-1 has its resource ready before sending the
6
INVITE request to UE-2. The terminating UE, UE-2, also has its resource ready before answering the
INVITE request with the first provisional response.
7
8
9
Note: This flow assumes UE-2 has sufficient resources available prior to receiving the INVITE.
10
11
12
Figure 1 Originating UE resource ready, terminating UE resource ready
13
1. INVITE (UE-1 to P-CSCF1)
14
15
UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds an SDP offer
16
containing 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 17
18
offered.
19
For this example, it is assumed that UE-1 is willing to establish a multimedia session comprising a video stream and
20
21
an audio stream. The video stream supports one H.263 codec as specified in [3]. The audio stream supports both
22
EVRC and SMV codecs as specified in [4].
23
24
In addition, UE-1 indicates that precondition is supported for this session. In the SDP offer, it indicates that resource
25
is already available at the local end point.
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples 1
Table 6.2.1.2-1 INVITE (UE-1 to P-CSCF1)
INVITE sip:UE-2@https://www.doczj.com/doc/181414040.html, SIP/2.0
From:
To:
Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348
Max-Forwards: 70
Route:
P-Preferred-Identity: "User-1"
P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411
Privacy: none
Require: sec-agree
Proxy-Require: sec-agree
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=98765432; spi-s=76543210;
port-c=13579; port-s=23456
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Supported: 100rel, precondition
Content-Type: application/sdp
Content-Length: xxx
v=0
o=- 3323527065117000 3323527065117000 IN IP4 10.20.1.100
s=-
c=IN IP4 10.20.1.100
t=0 0
m=audio 49500 RTP/AVP 97 99
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:97 EVRC/8000
a=ptime:20
a=rtpmap:99 SMV/8000
m=video 49600 RTP/AVP 34
b=AS:75
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:34 H263/90000
a=cif:1
2
3
2. INVITE (P-CSCF1 to I/S-CSCF1)
4
The P-CSCF1 adds itself to the Record-Route header and Via header. As the request is forwarded to an interface that 5
is not compressed, the P-CSCF1 SIP URI does not contain the "comp=sigcomp" parameter. The P-CSCF1 removes 6
the Security-Verify header and associated "sec-agree" option-tags prior to forwarding the request. As the Require 7
and Proxy-Require headers are empty, P-CSCF1 removes those headers completely.
8
The INVITE request is forwarded to the I/S-CSCF1.
9
10
11
3. INVITE (I/S-CSCF1 to I/S-CSCF2)
12
S-CSCF1 performs an analysis of the destination address, and determines the network operator to whom the 13
destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration 14
hidden, S-CSCF1 forwards the INVITE request directly to I-CSCF2 in the destination network.
15
16
The I-CSCF2 sends a query to the HSS to find out the S-CSCF2 of the called user. The HSS responds with the
1
address of the current S-CSCF2 for the terminating subscriber. I-CSCF2 forwards the INVITE request to the
2
S-CSCF2 that will handle the session termination. S-CSCF2 validates the service profile of this subscriber and
3
evaluates the initial filter criteria.
4
5
4-5. INVITE (I/S-CSCF2 to UE-2)
S-CSCF2 forwards the INVITE request to UE-2 via P-CSCF2.
6
7
8
6. 180 Ringing (UE-2 to P-CSCF2)
9
UE-2 has accepted both video and audio streams, and EVRC is the chosen codec for the audio stream. Since
10
resources are already available for UE-2, it sends a 180 (Ringing) response reliably with the SDP answer indicating
11
that resources are reserved at both endpoints.
12
7-10. 180 Ringing (P-CSCF2 to UE-1)
13
14
P-CSCF2 forwards the 180 (Ringing) response to UE-1 via I/S-CSCF2, I/S-CSCF1, and P-CSCF1. Table 6.2.1.2-2
15
shows the 180 (Ringing) response in detail.
16
17
Table 6.2.1.2-2 180 Ringing (P-CSCF1 to UE-1)
SIP/2.0 180 Ringing
From:
To:
Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348
Record-Route:
Contact:
P-Asserted-Identity: "User 2"
Privacy: none
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Require: 100rel, precondition
RSeq: 1000
Content-Type: application/sdp
Content-Length: xxx
v=0
o=- 33235270718000 33235270718000 IN IP4 10.30.1.24
s=-
c=IN IP4 10.30.1.24
t=0 0
m=audio 49700 RTP/AVP 97
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos optional local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:97 EVRC/8000
a=ptime:20
m=video 49702 RTP/AVP 34
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos optional local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:34 H263/90000
a=cif:1
18
19
20
11. PRACK (UE-1 to P-CSCF1)
21
UE-1 acknowledges the 180 (Ringing) response from UE-2 with a PRACK request as specified in [5]. (Table
6.2.1.2-3)
22
23
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples 1
If UE-1 determines to make any change in media flows, it includes a new SDP offer in the PRACK request sent to 2
UE-2. Otherwise, no SDP offer is included in the PRACK request.
3
4
Table 6.2.1.2-3 PRACK (UE-1 to P-CSCF1)
PRACK sip:UE-2@10.30.1.24:8805;comp=sigcomp SIP/2.0
From:
To:
Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100
P-Access-Network-Info: 3GPP2-1X-HRPD;ci-3gpp2=1234123412341234123412341234123411
CSeq: 2 PRACK
Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348
Max-Forwards: 70
Route:
RAck: 1000 1 INVITE
Content-Length: 0
5
6
12. PRACK (P-CSCF1 to I/S-CSCF1)
7
The P-CSCF forwards the PRACK request to S-CSCF. As the Proxy-Require header is empty, the P-CSCF removes 8
this header completely.
9
13-14. PRACK (I/S-CSCF1 to P-CSCF2)
10
11
The I/S-CSCF1 forwards the PRACK request to P-CSCF2 via I/S-CSCF2.
12
15. PRACK (P-CSCF2 to UE-2)
13
14
UE-2 starts alerting the user after it receives the PRACK request for the 180 (Ringing) response. UE-2 may also 15
alert 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.
16
17
18
16. 200 OK (UE-2 to P-CSCF2)
19
The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request.
20
21
17-20. 200 OK (P-CSCF2 to UE-1)
22
The 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 23
shows the 200 OK message going from P-CSCF1 to UE-1.
24
25
Table 6.2.1.2-4 200 OK (P-CSCF1 to UE-1)
SIP/2.0 200 OK
From:
To:
Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100
CSeq: 2 PRACK
Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348
Content-Length: 0
26
27
21. 200 OK (UE-2 to P-CSCF2)
28
When the user at UE-2 answers the call, UE-2 generates a 200 OK response towards UE-1 to answer the INVITE 29
request.
30
31
22-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-5
32
33
shows 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 OK
From:
Record-Route:
Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Contact:
2 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)
5
6
7 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.0
From:
Via: SIP/2.0/UDP 10.20.1.100:5060;comp=sigcomp;branch=z9hG4bK-792-1d9290-49ff0c31 Max-Forwards: 70
Route:
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples 1
2
6.2.2 Scenario
2
3
This section covers the scenario where the originating UE’s resources are ready before sending INVITE, and the 4
terminating UE’s resources are not ready before sending the first provisional response
5
6
6.2.2.1 Assumptions
7
6.2.2.2 Call
Flow
8
9
This scenario assumes that the terminating UE, UE-2, does not have the resource ready before sending the first
provisional response. UE-2 may send a 183 (Session Progress) response unreliably. At the same time, UE-2 also 10
11
starts the resource reservation process. Once the resource is ready at UE-2 side, the UE-2 sends 180 (Ringing) 12
response reliably to UE-1, including an SDP answer to indicate that the resource is ready. The SDP offer/answer
13
exchanges are the same as those in Scenario 1.
14
15
Figure 2 Originating UE resource ready, terminating UE resource not ready
16
1
3
6.2.3 Scenario
2
3
This section covers the scenario where the originating UE’s resources are not ready before sending INVITE, and 4
terminating UE’s resources are ready before sending the first provisional response.
5
6.2.3.1 Assumptions
6
The call flow in this section assumes that the originating UE, UE-1, has resources ready before sending the PRACK 7
request to the first provisional response. In case UE-1’s resources are not ready before sending the PRACK request 8
for the first provisional response (183), then UE-1 needs to send an UPDATE request to UE-2 to indicate that 9
resources are ready, after the resource reservation is completed.
10
flow
6.2.3.2 Call
11
12
The following section applies to the case where UE-1 has no resource reserved before sending the initial INVITE 13
request to UE-2.
14
15
X.S0013-009-0 v1.0 IMS/MMD Call Flow Examples
1
2
Figure 3 Originating UE not ready, Terminating UE ready
3
4
1-5. INVITE (UE-1 to P-CSCF1)
5
UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds a SDP 6
containing characteristics of each codec, and assigns local port numbers for each possible media flow. Multiple 7
media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices 8
offered.
9
10
For this example, it is assumed that UE-1 desires to establish a multimedia session comprising a video stream and an 11
audio stream. The video stream supports one H.263 codec. The audio stream supports both EVRC and SMV codec.
12
13
UE-1 does not indicate that precondition is required for this session, but indicates that it is supported. (This approach optimizes compatibility and performance when interworking with 3rd party (non-MMD) terminals). In the SDP body,
14
15
UE-1 indicates the current resource status and that the desired resource status is optional. UE-1 also sets every media 16
stream to inactive mode by using the ‘a=inactive’ SDP attribute in the SDP offer. Detecting the QoS precondition 17
content in the SDP, UE-2 indicates resource reservation, but the session can continue regardless of whether or not 18
this reservation is possible.
19
20
UE-1 does not indicate that reliable provisional responses are required, but indicates that they are supported. This 21
gives UE-2 the ability to reliably send only those responses that are most appropriate.
1
2
Table 6.2.3.2-7 INVITE (UE-1 to P-CSCF1)
INVITE sip:UE-2@https://www.doczj.com/doc/181414040.html, SIP/2.0
Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348
From:
To:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@https://www.doczj.com/doc/181414040.html,
CSeq: 1 INVITE
Max-Forwards: 70
Route:
P-Preferred-Identity: "User-1"
P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411
Privacy: none
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Require: sec-agree
Proxy-Require: sec-agree
Supported: 100rel, precondition
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=9876543; spi-s=3456789;
port-c=8642; port-s=7531
Content-Type: application/sdp
Content-Length: xxx
v=0
o=- 2987935614 2987935614 IN IP4 100.200.1.1
s=-
c=IN IP4 100.200.1.1
t=0 0
m=audio 10500 RTP/AVP 97 99
b=AS:25.4
a=inactive
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:97 EVRC/8000
a=ptime:20
a=rtpmap:99 SMV/8000
m=video 10600 RTP/AVP 34
b=AS:75
a=inactive
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:34 H263/90000
a=cif:1
3
4
6-10. 183 (P-CSCF1 to UE-1)
5
UE-2 accepts both video and audio streams, and chooses EVRC as the codec for the audio stream. An SDP answer is 6
included to assist UE-1 in completing resource reservation as early as possible. The SDP answer includes precondition status.
7
8
声部划分体系 一、绪论 声音生理条件的不同构成了声部类型的不同。不同类型的声音条件，构成了不同类型的声音声部。将女高音划分为不同的声部，这是在共性上承认了女高音之间的差别。根据各声部的生理特点，采取具有针对性的训练，这是一种严谨科学的教学方式。当然，具体到个别声音，我们会发现，即使同一声部类型的声音，它们之间也存在着很多细微的差别，其中的关系属于共性与个性的关系。因此，在声乐教学中，根据声部划分理论的指导，尊重每个声音的生理特征显得尤为重要。是否能够根据学生的生理特点，正确决定学生的声音声部类型，从声乐教学技术层面上看，这是对每位声乐教师的一个严峻考验。 声乐作品选择，以歌剧为例，歌剧的每首咏叹调都是作曲家为某个特定的角色而写，而每个角色都属于特定的声部类型。作曲家在音乐创作过程中，充分地考虑到了角色的声部特征，因此，每首咏叹调的音乐都相当具有针对性。有些曲目，甚至是作曲家专门为某位歌唱家而写。为此，每位歌唱者必须选择适合自己声部的咏叹调演唱。能否根据学生的声部类型，为学生选择适合的声乐作品演唱，这在艺术修养层面，向每位声乐教师提出了更高的艺术要求。 总体来说，声部类型的确定是一项复杂的声乐教学活动，它不能取决于教师的僵硬教学方法和模仿某位歌唱家的演唱方式。在声乐教学工作中，根据学生自身的生理条件，正确地确定学生的声部；同时，根据学生的声部类型，选择演唱适合学生声部的声乐作品，这是声乐教学中重要的教学内容之一。错误地确定学生的声部，可能会限制一个优秀学生的歌唱发展，而错误地让学生演唱不属于自己声部的作品，可能会毁灭学生的声乐演唱生命。美声声部划分体系所承担的学术任务就是解决声部划分和声部曲目问题。无论对声乐教师还是对声乐演唱者，都应当精确地掌握美声声部划分体系。 二、西洋歌剧艺术的声部划分体系 经过上百年的发展变化，歌剧艺术已经成为一门成熟的艺术形式。声部划分方式、声部划分依据和声部嗓音训练标准构成了完整的声乐学科声部划分体系。在这一体系中包括德国、法国和意大利等国的声部划分体系，其中当属德国声乐学科声部划分体系（Fach）系统性最高。本套教材以德国声部划分体系为主，兼顾意大利和法国声部划分体系。 1.何为德国声乐学科声部划分体系（Fach） 德国声乐学科声部划分体系（Fach）是西方歌剧艺术广为采用的声部划分系统之一。根据歌唱演员自身生理条件、声音演唱能力和声音的具体质量，该体系界定了各类型声部以及每个声部的演唱曲目。德国声乐学科声部划分体系被称为Fach。Fach在德文中有两个意思：一是抽屉、格层。二是学科、专业、课程。目前，在国内出版的音乐专业词典中，尚未对该专业术语作确切的界定。为此，笔者暂且将其称为“声乐学科声部划分体系”，简称“声部划分体系”。这里有两点需要说明：（1）虽然德国声部划分体系对各声部及各声部演唱的角色进行了非常系统的界定，但该系统也承认声音的动态性。由于演唱者的生理发展和技术改善等方面的因素，声音可能从一个声部转向另一个声部，曲目的选择也可以拓展至不同声部的曲目。（2）法国和意大利等国也有自己的声部划分方法，但从系统化角度来看，德国声部分类法比较完善，而且这些系统在本质上也没有绝对的不同，只是名称略有出入而已。 2.声部划分依据的声音生理
声部划分体系 -全面版 作为一门成熟的艺术形式，美声声部类型分类，既具有科学成分，但更重要的是传统艺术审美因素，超越传统艺术形式界定的创新等于破坏艺术形式。我们必须清楚地意识到，尽管掌握稳定的声音技巧可以拓展我们声音的音域、质量和表现力，但学习声音技巧的目的绝不是锻炼歌唱者去掌握所有声部的表现手段。我们必须尊重美声艺术价值标准，必须尊重美声声部划分体系的技术标准。尊重生理条件、准确确定声部类型、选择适合自己声部的演唱曲目是每个歌唱者必须遵循的学习原则。只有这样，在歌唱实践中才能真正做到善待自己的声音、合理使用自己的声音。 一、绪论 声音生理条件的不同构成了声部类型的不同。不同类型的声音条件，构成了不同类型的声音声部。将女高音划分为不同的声部，这是在共性上承认了女高音之间的差别。根据各声部的生理特点，采取具有针对性的训练，这是一种严谨科学的教学方式。当然，具体到个别声音，我们会发现，即使同一声部类型的声音，它们之间也存在着很多细微的差别，其中的关系属于共性与个性的关系。因此，在声乐教学中，根据声部划分理论的指导，尊重每个声音的生理特征显得尤为重要。是否能够根据学生的生理特点，正确决定学生的声音声部类型，从声乐教学技术层面上看，这是对每位声乐教师的一个严峻考验。 声乐作品选择，以歌剧为例，歌剧的每首咏叹调都是作曲家为某个特定的角色而写，而每个角色都属于特定的声部类型。作曲家在音乐创作过程中，充分地考虑到了角色的声部特征，因此，每首咏叹调的音乐都相当具有针对性。有些曲目，甚至是作曲家专门为某位歌唱家而写。为此，每位歌唱者必须选择适合自己声部的咏叹调演唱。能否根据学生的声部类型，为学生选择适合的声乐作品演唱，这在艺术修养层面，向每位声乐教师提出了更高的艺术要求。 总体来说，声部类型的确定是一项复杂的声乐教学活动，它不能取决于教师的僵硬教学方法和模仿某位歌唱家的演唱方式。在声乐教学工作中，根据学生自身的生理条件，正确地确定学生的声部；同时，根据学生的声部类型，选择演唱适合学生声部的声乐作品，这是声乐教学中重要的教学内容之一。错误地确定学生的声部，可能会限制一个优秀学生的歌唱发展，而错误地让学生演唱不属于自己声部的作品，可能会毁灭学生的声乐演唱生命。美声声部划分体系所承担的学术任务就是解决声部划分和声部曲目问题。无论对声乐教师还是对声乐演唱者，都应当精确地掌握美声声部划分体系。 二、西洋歌剧艺术的声部划分体系 经过上百年的发展变化，歌剧艺术已经成为一门成熟的艺术形式。声部划分方式、声部划分依据和声部嗓音训练标准构成了完整的声乐学科声部划分体系。在这一体系中包括德国、法国和意大利等国的声部划分体系，其中当属德国声乐学科声部划分体系（Fach）系统性最高。本套教材以德国声部划分体系为主，兼顾意大利和法国声部划分体系。 1.何为德国声乐学科声部划分体系（Fach） 德国声乐学科声部划分体系（Fach）是西方歌剧艺术广为采用的声部划分系统之一。根据歌唱演员自身生理条件、声音演唱能力和声音的具体质量，该体系界定了各类型声部以及每个声部的演唱曲目。德国声乐学科声部划分体系被称为Fach。Fach在德文中有两个意思：一是抽屉、格层。二是学科、专业、课程。目前，在国内出版的音乐专业词典中，尚未对该专业术语作确切的界定。为此，笔者暂且将其称为“声乐学科声部划分体系”，简称“声部划分体系”。这里有两点需要说明：（1）虽然德国声部划分体系对各声部及各声部演唱的
客服中心呼叫中心岗位职责
呼叫中心各岗位职责规范及岗位要求 1.主管职责规范及岗位要求 1.1岗位职责 （1）组织制定部门战略目标，并制定具体实施步骤。 （2）制定部门各项管理制度，包括绩效管理制度、排班制度、请假和年休制度、现场管理制度，并督导各项管理规章制度的制定及执行。 （3）结合考核结果，定期调整部门下一阶段优化目标和方案，并微调部门绩效管理实施细则。 （4）就部门所遇疑难客服问题与其他部门沟通（包括中国移动客服中心、工程部、数据部、运行维护部、安装维修队等），并协商处理方案 （5）掌握和了解部门内外动态，及时向公司高层反映客服近况和存在问题，并提出改进建议。 1.2 技能要求 （1）.熟练掌握公司相关咨询、报修、投诉、勘察、稽查等相关流程，并掌握执行相关流程的系统操作。 （2）具有良好的沟通表达能力，能较好地与坐席、其他部门人员或主管沟通相关信息。 （3）熟悉现代企业管理制度，具备较强的管理能力，能较好带领部门完成公司规定的工作。 2.副主管职责职责规范及岗位要求 2.1岗位职责 （1）根据公司对于呼叫中心的部门目标要求，结合呼叫中心的现状，协助部门主管制定呼叫中心各项管理制度，包括各岗位职责制定和调整、奖金分配制度、绩效指标的制定、分析以及相应的考核方式、呼叫中心的话务量预测和相应排班方式等。并在执行中，通过对结果数据的分析，确定执行效果，并依此作出动态调整，不断提升呼叫中心整体运作效率。 （2）协助分管主任制定呼叫中心各项业务流程，并在流程的执行中，针对座席
工作时所遇到的细节问题答疑授惑，针对与其他部门工作衔接时出现的问题及时沟通，并不断完善、补充业务流程。 （3）当呼叫中心内部或者外部（如维修客服）流程发生变化时，提出BOSS系统相应需求，并在BOSS系统需求实现后，制定操作手册，指导座席使用和适应新的操作方式，并不断加以完善BOSS客服系统，以便提高系统运作效率。（4）协助主管部门遇到的疑难客服问题，与其他部门沟通（包括中国移动客服中心、工程部、数据部、运行维护部、安装维修队等），并协商处理方案。. （5）负责呼叫中心计算机和运营系统的日常维护、简单维修和管理。 （6）完成领导交办的其他事项 2.2技能要求 （1）熟练掌握公司相关咨询、报修、投诉、勘察、稽查等相关流程，并掌握执行相关流程的系统操作。 （2）具有良好的沟通表达能力，能较好地与坐席、其他部门人员或主管沟通相关信息。 （3）掌握一定的现代企业管理知识，具备一定的管理能力，能较好的协助主管管理部门，完成公司交办的任务。 3.班长职责规范及岗位要求 3.1岗位职责 （1）对于已明确客服流程，却因相关部门执行问题而引发的客户投诉，及时联系相关部门，寻求处理方案。并在得知处理方案后立即反馈至坐席，以便坐席回复用户。 （2）对于各部门发起的抢修，及时创建抢修单，并通过短信方式通知相关人员。在得知抢修结束信息后，及时安排坐席回访，并在回访确认后，完成抢修单。（3）负责对坐席的业务管理与指导工作；检查、监督员工岗位职责执行情况。严格执行《呼叫中心现场管理及卫生制度》，认真填写值班日志。对违反各项制度、业务规程、劳动纪律，要及时向主管反映。 （4）处理在工作中的重要事件及突发事件，及时上报呼叫中心主管，同时进行紧急处理。
呼叫中心运营手册 一、组织结构 一、呼叫中心 1、经理的主要职责 呼叫中心决策人，制定呼叫中心的发展方向和政策。 负责协调呼叫中心与公司其他部门之间的关系，并召集会议调整流程和服务容，确保客户的需求受到充分的重视。 负责管理整个呼叫中心的运作表现、质量保险、生产率及成本效率控制等目标，并全面监管日常客户服务。 规划、管理及控制呼叫中心的运作，以便用有效及高效的方法达到品质与成本的目标。 在符合优质的服务目标下，确保呼叫中心的资源得到最有效的利用。 完善各类工作规文件，并确保其执行品质。 发现及校正任何影响生产力及获利方面的营运问题。培养积极的及专业的客户服务团队。 2、组长主要职责
监督及管理小组成员动作并给予客户12小时有效服务。 监督并评估小组成员的工作质量及效率，必要时决定并采取改善措施。 提供指导及支援以促进小组成员的服务质量及日常操作的顺利实施。 监督流量状况。 处理及解决来自小组成员的用户投诉及复杂的用户咨询。 积极地获取回馈，并向运营经理推荐有关执行效率改进的方案。 每个班长负责8-12名员工，直接向经理汇报。 协助主管训练新进营销专员。确保团队所有员工明确项目进度及个人目标。 负责新进组员受训后的辅导责任。 负责小组的管理（如主管交办的任务，准客户冲突的处理，出勤等）与行政工作巧妙地处理及解决来自小组成员的疑难客户咨询。 负责小组的士气提升。 每天10分钟与组员开通气会。 协助招聘经理扩展小组组织，补充人力，并负责招聘及面谈。 保守业务。 执行主管交办的任务。 日常管理 训练 控制 日常管理包括： 以一个管理小组的形式共同协作，将会使步骤一致、信息清晰，并且共同做出好的决定。
呼叫中心制度及管理流 程 集团标准化小组：[VVOPPT-JOPP28-JPPTL98-LOPPNN]
一、呼叫中心主管岗位职责 1、管理客服（座席）专员电话接听工作，对疑难问题予以指导； 2、主持征期内的客服专员每日一会，进行及时的培训、答疑； 3、统计客服专员每月的考核，提供工资、奖金依据； 4、实时关注CRM，安排录单工作，对CRM 中变更信息及时修改； 5、客服平时出现请假、缺席情况的，及时安排并调配人员； 6、安排客服专员的回访工作，向客服分发回访名单，并定时回收；汇总回访情况，进行总结，处理回访过程中企业的需求。； 7、负责跟进及处理客户投诉等问题； 8、协调、跟进与区域之间相关服务问题的处理； 9、负责统计呼叫中心相关数据。 二、呼叫中心员工岗位职责 1、负责所有客户的电话咨询、问题解答； 2、负责电话回访（协议、上门、返卡、电话留言及网站留言）； 3、负责做好日报、月报，及时反馈信息的统计、分析和汇报； 4、负责有服务需求客户的电话营销工作； 5、完成上级安排的其他工作。 三、呼叫中心服务标准 （一）电话接听服务态度 1、接通电话时，应说：“您好，中国××（工号）为您服务！” 2、客户不出声时，应说：“您好，请问有什么可以帮您？” 3、用户仍不出声，应说：“对不起，听不到您的声音，请稍后再拨！” 4、用户等待超过10秒，应说：“对不起，请稍等！” 5、听不懂用户方言，应说：“您好，请讲普通话好吗？” 6、听不清用户问题，应说：“对不起，请您大声一点好吗？”“对不起，请您讲慢一点好吗？”“对不起，请您重复一遍好吗？” 7、取消“静音”恢复通话，应说：“对不起，让您久等了！” 8、解答完毕，应说：“请问您还有什么问题吗？” 9、不能当场解答疑难问题，应说：“请稍等，您的问题正在记录……请讲！”“您的问题我复述一遍好吗？”“您的问题稍后我们会尽快回复您。” 10. 回复疑难问题时，应说：“您好，这里是湖北哲科服务热线。您上次（*月*日）咨询的关于***问题，现在给您回复。” 11. 需要用户记录时，应说：“请您记录……” 12. 电话结束，用户表示感谢时，应说：“不用谢/不客气，欢迎您再次来电！” 13. 用户打错电话，应说：“您好！对不起，这里是湖北哲科服务热线，您打错电话了！”并尽可能地告知正确的去电方向。 14. 用户态度不友好，应说：“谢谢您的宝贵意见！我们会及时向领导反映。”“我们的工作还需要改进，感谢您的支持！” （二）电话接听岗位规范
解剖学试题及答案--呼吸系统（二） 一、填空题 1?呼吸道包括（）、（）、（）、（）和（）。 2. 上鼻甲或最上鼻甲后上方与鼻腔顶之间的凹陷部分称（6），鼻旁窦 中（7）开口于此处。 3. 开口于中鼻道的鼻旁窦有（）、（）、（）、（）。 4. 构成喉支架的软骨包括不成对的（）（）、（）和成对的（）。 5. 环状软骨是由（）、（）两部构成，是喉软骨中惟一呈环形的软骨，对气管起支撑作用。 6. 通常所称的声带是指（）和（）以及由其覆盖的（）三者组成的结构而言。 7. 喉腔内上方的一对粘膜皱襞称（）、下方的一对粘膜皱襞称（）。上、下两对粘膜皱襞将喉腔分为二者上方的（）、二者下方的（）、二者之间的（）三部。 8. 气管分为颈、胸二部，在（）与第4胸椎骨体下缘连线的平面上 分为左、右主支气管。 9. 壁胸膜按其所附着的部位可分为（）、（）、（）、（）。 10. 喉腔中两声襞之间的裂隙称（）。 11. 气管隆嵴的高度相当于（）或（）水平。 12. 吸气时，膈肌处于（）状态，此时胸腔容积（）。
13. 左肺前缘锐薄，其下分有凹入的（），再下方有向下突出的 （）。 14. 胸膜腔最低点为（），临床上又称为（）。 15. 胸膜下界的投影点在腋中线与（）相交，在锁骨中线与（）相交。 16. 纵隔四分法，首先将其分为（）和（），后者又被分为（）、（）和（）。 17. 主支气管较左主支气管（）、（）其走向（）。 18. 两侧胸膜前界返折时形成两个三角形无胸膜区，即（）和（）。 三、正误判断、改错题 1. 气管上端与喉相连，向下在颈静脉切迹平面分左、右主支气管。 2. 鼻前庭是鼻腔的主要部分，由骨性鼻腔内衬粘膜而成。 3. 蝶窦开口与上鼻道。 4. 环状软骨是喉软骨中惟一完整的软骨环，平对第6颈椎，是颈部重要的体表标志。 5. 声门裂是喉腔最狭窄的部位。 6. 喉腔向上通气管，向下和咽相交通。 7. 声襞是喉粘膜覆盖声韧带和声带肌而成。 8. 成年男性的喉结很明显，女性的喉结一般比男性略低。 9. 左主支气管较垂直，而右主支气管较水平，所以气管异物易落入右主支气管。
概念、方法、测定：呼叫中心的流程管理 呼叫中心的流程管理 流程管理对于呼叫中心管理人是一项很重要的技能.我也经常被读者听众问及这一话题.。之所以先谈了十几个其它题目是因为在我看来，呼叫中心的流程管理与企业其它流程管理没有太大的分别,作为一个管理人，此为必备能力。一个管理人除了管人之外就是管事，而管事是无法回避流程管理的. 一、流程管理的基本概念 企业的业务流程是指围绕企业目标有序地进行一系列活动以产生某种特定结果的过程。这个结果可以是一种有形产品，也可能是无形的服务。在呼叫中心则主要为后者。在一个设计完整的流程中，每一个活动都是建立在前一个活动结果之上并对整体结果产生作用.管理流程要求连续性与可重复性。你不能设想两个情况相同的客户打电话问类似的问题会得到两个相去甚远的答复。你也很难想像同一个客户隔一天来电购买同样产品会得到完全不同的服务内容。但看一下我们许多呼叫中心这类现象并不少见。这种"无章可循"或"有章不循"是许多企业低效率、低士气、高成本、高投诉的重要原因，也是无法建立良好客户体验的原因
之一。 在呼叫中心中，面对客户的流程主要有三大类：核实流程，服务实现流程和知识流程。我将三个典型的流程图列出并希望能够省略文字解释的篇幅。根据业务类别的不同，围绕着主要流程还可以有许多子流程。如在销售型呼叫中心中服务实现流程中就可能会销售线索派送跟踪流程和立即销售流程等。而在立即销售流程中可能又会有付款收费流程的等。 二、流程管理的方法与工具 标准化的流程管理中最常用的就是流程图。这种树状图代表了在各个环节上具体工作的表现与递送。通常用圆圈代表起点与终点，方块代表任务，箭头代表关系，菱形则表示决策分叉点。用运算表可以产生其它几种相关文档用于流程的建立与实施追踪.这些文档包括ProjectPlanning,Worksheet,GanttChart,ControlSheet,Logo fErrors,WorkPlan,SOP和Checklist。有些用时间作横坐标，有些则类似流水帐。不少企业都有这些文档的标准模板，如果没有，负责运营的经理应当负责建立。 SOP是标准操作程序或类似我们通常所说的操作手册。该手册
解剖学试题及答案--呼吸系统(二) 一、填空题 1. 呼吸道包括( ) 、( ) 、( ) 、( ) 和( ) 。 2. 上鼻甲或最上鼻甲后上方与鼻腔顶之间的凹陷部分称(6) ，鼻旁窦中(7) 开口于此处。 3. 开口于中鼻道的鼻旁窦有( ) 、( ) 、( ) 、( ) 。 4. 构成喉支架的软骨包括不成对的( )( ) 、( ) 和成对的() 。 5. 环状软骨是由( ) 、( ) 两部构成，是喉软骨中惟一呈环形的软骨，对气管起支撑作用。 6. 通常所称的声带是指( ) 和( ) 以及由其覆盖的( ) 三者组成的结构而言。 7. 喉腔内上方的一对粘膜皱襞称( ) 、下方的一对粘膜皱襞称( ) 。上、下两对粘膜皱襞将喉腔分为二者上方的( ) 、二者下方的( ) 、二者之间的( ) 三部。 8. 气管分为颈、胸二部，在( ) 与第 4 胸椎骨体下缘连线的平面上分为左、右主支气管。 9. 壁胸膜按其所附着的部位可分为( ) 、( ) 、( ) 、( ) 。 10. 喉腔中两声襞之间的裂隙称( ) 。 11. 气管隆嵴的高度相当于( ) 或( ) 水平。 12. 吸气时，膈肌处于( ) 状态，此时胸腔容积( ) 。 13. 左肺前缘锐薄，其下分有凹入的( ) ，再下方有向下突出的( ) 。
14. 胸膜腔最低点为( ) ，临床上又称为( ) 。 15. 胸膜下界的投影点在腋中线与( ) 相交，在锁骨中线与( ) 相交。 16. 纵隔四分法，首先将其分为( ) 和( ) ，后者又被分为( ) 、( ) 和( ) 。 17. 主支气管较左主支气管( ) 、( ) 其走向( ) 。 18. 两侧胸膜前界返折时形成两个三角形无胸膜区，即( ) 和( ) 。 三、正误判断、改错题 1. 气管上端与喉相连，向下在颈静脉切迹平面分左、右主支气管。 2. 鼻前庭是鼻腔的主要部分，由骨性鼻腔内衬粘膜而成。 3. 蝶窦开口与上鼻道。 4. 环状软骨是喉软骨中惟一完整的软骨环，平对第6 颈椎，是颈部重要的体表标志。 5. 声门裂是喉腔最狭窄的部位。 6. 喉腔向上通气管，向下和咽相交通。 7. 声襞是喉粘膜覆盖声韧带和声带肌而成。 8. 成年男性的喉结很明显，女性的喉结一般比男性略低。 9. 左主支气管较垂直，而右主支气管较水平，所以气管异物易落入右主支气管。 10. 两肺尖均高出锁骨外侧1 / 3 的上方约2 ～3cm 。 11. 胸膜腔呈负压状态。
视频通话分析 1：IP网络通讯协议 在传统电话系统中，一次通话从建立系统连接到拆除连接都需要一定的信令来配合完成。同样，在IP电话中，如何寻找被叫方、如何建立应答、如何按照彼此的数据处理能力发送数据，也需要相应的信令系统，一般称为协议。目前在国际上，比较有影响的IP电话方面的协议包括ITU-T提出的H.323协议和IETF提出的SIP协议。而MGCP主要应用于运营商市场，在行业市场鲜有应用。 1.1：协议概要分析 1.1.1：H323协议 H.323是ITU-T第16工作组的建议，由一组协议构成，其中有负责音频与视频信号的编码、解码和包装，有负责呼叫信令收发和控制的信令，还有负责能力交换的信令。H.323的第4版本具备做电信级大网的特征，以它为标准构建的IP电话网能很容易地与传统PSTN（公共交换电话网络）电话网兼容，从这点上看，H.323更适合于构建电话到电话的电信级大网。 H.323协议族规定了在主要包括IP网络在内的基于分组交换的网络上提供多媒体通信的部件、协议和规程。H.323一共定义了四种部件：终端，网关，网守和多点控制单元。利用它们，H.323可以支持音频、视频和数据的点到点或点到多点的通信。H.323协议族包括用于建立呼叫的H.225.0、用于控制的H.245、用于大型会议的H.332 以及用于补充业务的H.450.X等。H.323 协议中包含3条信令控制信道：RAS (R=注册:Registration、A=许可:Admission 和S=状态:Status)信令信道、呼叫信令信道和H.245 控制信道。3 条信道的协调工作使得H.323的呼叫得以进行。 H.323建议是一个较为完备的建议书，它提供了一种集中处理和管理的工作模式，这种工作模式与电信网的管理方式是匹配的，这就是为什么电信网中使用的IP电话几乎无例外地都采用了基于H.323的IP电话工作模式? 1.1.2：SIP协议 SIP协议，即Session Initiation Protocol，是另一套IP电话的体系结构,是一个与H.323并列的协议。它是一个工作在TCP/IP应用层的信令控制协议，用于创建、修改和终止一个会话。这里所指的会话是一个比较宽泛的概念，它既可以是传统的语音通信，也可以是视频、即使消息、在线游戏等，同时参与对话的实体可以是两个，也可以是多个。 SIP协议是一种基于文本的会话控制协议，它的消息都是由ASCII码组成的，因此易于阅读和理解。SIP协议由IETF组织研究并提交RFC，当前关于SIP协议的最新标准是RFC3261。由于IETF阵营汇聚的都是互联网方面的专家，因此SIP在开发上自然借鉴了其他TCP/IP相关协议的模式，在消息格式、认证模式、媒体描述等方面都完全采用了已有的标准，这样无疑加快了SIP协议的推广，让大量具有TCP/IP协议及应用开发经验的人可以迅速地接受SIP。 目前SIP协议的发展及推广非常迅速，IT领域的各大厂商都相继推出SIP的产品。例如微软的Live Communicator系统就选择了SIP协议；CISCO的融合通信系统采用了SIP；3GPP
呼叫中心各岗位职责规范及岗位要求 1.主管职责规范及岗位要求 1.1岗位职责 （1）组织制定部门战略目标，并制定具体实施步骤。 （2）制定部门各项管理制度，包括绩效管理制度、排班制度、请假和年休制度、现场管理制度，并督导各项管理规章制度的制定及执行。 （3）结合考核结果，定期调整部门下一阶段优化目标和方案，并微调部门绩效管理实施细则。 （4）就部门所遇疑难客服问题与其他部门沟通（包括中国移动客服中心、工程部、数据部、运行维护部、安装维修队等），并协商处理方案 （5）掌握和了解部门内外动态，及时向公司高层反映客服近况和存在问题，并提出改进建议。 1.2技能要求 （1）.熟练掌握公司相关咨询、报修、投诉、勘察、稽查等相关流程，并掌握 执行相关流程的系统操作。 （2）具有良好的沟通表达能力，能较好地与坐席、其他部门人员或主管沟通相关信息。 （3）熟悉现代企业管理制度，具备较强的管理能力，能较好带领部门完成公司规定的工作。 2.副主管职责职责规范及岗位要求 2.1岗位职责 （1）根据公司对于呼叫中心的部门目标要求，结合呼叫中心的现状，协助部门主管制定呼叫中心各项管理制度，包括各岗位职责制定和调整、奖金分配制度、绩效指标的制定、分析以及相应的考核方式、呼叫中心的话务量预测和相应排 班方式等。并在执行中，通过对结果数据的分析，确定执行效果，并依此作出 动态调整，不断提升呼叫中心整体运作效率。 （2）协助分管主任制定呼叫中心各项业务流程，并在流程的执行中，针对座席
工作时所遇到的细节问题答疑授惑，针对与其他部门工作衔接时出现的问题及 时沟通，并不断完善、补充业务流程。 （3）当呼叫中心内部或者外部（如维修客服）流程发生变化时，提出BOSS系统相应需求，并在BOSS系统需求实现后，制定操作手册，指导座席使用和适 应新的操作方式，并不断加以完善BOSS客服系统，以便提高系统运作效率。（4）协助主管部门遇到的疑难客服问题，与其他部门沟通（包括中国移动客服中心、工程部、数据部、运行维护部、安装维修队等），并协商处理方案。. （5）负责呼叫中心计算机和运营系统的日常维护、简单维修和管理。 （6）完成领导交办的其他事项 2.2技能要求 （1）熟练掌握公司相关咨询、报修、投诉、勘察、稽查等相关流程，并掌握执行相关流程的系统操作。 （2）具有良好的沟通表达能力，能较好地与坐席、其他部门人员或主管沟通相关信息。 （3）掌握一定的现代企业管理知识，具备一定的管理能力，能较好的协助主管管理部门，完成公司交办的任务。 3.班长职责规范及岗位要求 3.1岗位职责 （1）对于已明确客服流程，却因相关部门执行问题而引发的客户投诉，及时联系相关部门，寻求处理方案。并在得知处理方案后立即反馈至坐席，以便坐席 回复用户。 （2）对于各部门发起的抢修，及时创建抢修单，并通过短信方式通知相关人员。在得知抢修结束信息后，及时安排坐席回访，并在回访确认后，完成抢修单。（3）负责对坐席的业务管理与指导工作；检查、监督员工岗位职责执行情况。严格执行《呼叫中心现场管理及卫生制度》，认真填写值班日志。对违反各项制度、业务规程、劳动纪律，要及时向主管反映。 （4）处理在工作中的重要事件及突发事件，及时上报呼叫中心主管，同时进行紧急处理。
智能应答业务方案说明
一、业务描述 主叫拨打被叫，被叫振铃，主叫听到被叫的振铃声，如果被叫申请了该业务，被叫可以拒绝挂断呼叫，之后会立刻收到一个文字菜单，如：1开会；2关机；3不在服务区；被叫做选择并按键，这时主叫就会听到相应语音，如：“对不起被叫已关机，请稍候再拨”。 二、方案实现 该业务是被叫侧业务，为申请该业务的用户设置遇忙前转，这样呼叫该用户的呼叫在被叫拒绝挂断时呼叫将被转移到ivr平台上，由ivr平台再调用map信令平台完成ussd信令的菜单交互交互。 二.1平台组成说明 ussd接口，ivr平台收到呼叫后通过该接口命令map信令平台发送ussd信令，并将用户的按键返回给ivr平台，并播放相应语音。
1 主叫拨打被叫，电信网络接续呼叫，被叫振铃 2 被叫拒绝挂断，该用户是业务用户，设置了呼叫遇忙前转，网络因此将主叫呼叫前转到指定ivr平台上，平台继续播放提示语音。 3 ivr平台向信令平台发送ussd菜单推送请求。 4 信令平台向被叫推送ussd菜单。 5 被叫按键应答，按键信息会送给信令平台。 6 信令平台将被叫按键信息回送给ivr平台。 7 ivr平台查询数据库，跟据不同的按键选择不同的播放语音。
1 交换机前转呼叫，主叫的遇忙前转，发送iam 2 ivr平台回送acm、anm接收呼叫，继续播放振铃提示 3 ivr平台向信令平台发送begin请求，请求内容为一个字符串菜单 4 信令平台发送map信令unstructuredSS_Request 5 被叫应答后收到unstructuredSS_RequestRes响应，携带被叫按键，continue转给ivr平台 6 ivr平台发送end结束ussd对话，并分析被叫按键对主叫播放相应提示语音
一、填空题 1. 呼吸道包括 ( ) 、 ( ) 、 ( ) 、 ( ) 和 ( ) 。 2. 上鼻甲或最上鼻甲后上方与鼻腔顶之间的凹陷部分称 (6) ，鼻旁窦中 (7) 开口于此处。 3. 开口于中鼻道的鼻旁窦有 ( ) 、 ( ) 、 ( ) 、 ( ) 。 4. 构成喉支架的软骨包括不成对的 ( )( ) 、 ( ) 和成对的 () 。 5. 环状软骨是由 ( ) 、 ( ) 两部构成，是喉软骨中惟一呈环形的软骨，对气管起支撑作用。 6. 通常所称的声带是指 ( ) 和 ( ) 以及由其覆盖的 ( ) 三者组成的结构而言。 7. 喉腔上方的一对粘膜皱襞称 ( ) 、下方的一对粘膜皱襞称 ( ) 。上、下两对粘膜皱襞将喉腔分为二者上方的 ( ) 、二者下方的 ( ) 、二者之间的 ( ) 三部。 8. 气管分为颈、胸二部，在 ( ) 与第 4 胸椎骨体下缘连线的平面上分为左、右主支气管。 9. 壁胸膜按其所附着的部位可分为 ( ) 、 ( ) 、 ( ) 、 ( ) 。 10. 喉腔中两声襞之间的裂隙称 ( ) 。 11. 气管隆嵴的高度相当于 ( ) 或 ( ) 水平。 12. 吸气时，膈肌处于 ( ) 状态，此时胸腔容积 ( ) 。 13. 左肺前缘锐薄，其下分有凹入的 ( ) ，再下方有向下突出的( ) 。
14. 胸膜腔最低点为 ( ) ，临床上又称为 ( ) 。 15. 胸膜下界的投影点在腋中线与 ( ) 相交，在锁骨中线与 ( ) 相交。 16. 纵隔四分法，首先将其分为 ( ) 和 ( ) ，后者又被分为 ( ) 、( ) 和 ( ) 。 17. 主支气管较左主支气管 ( ) 、 ( ) 其走向 ( ) 。 18. 两侧胸膜前界返折时形成两个三角形无胸膜区，即 ( ) 和 ( ) 。 三、正误判断、改错题 1. 气管上端与喉相连，向下在颈静脉切迹平面分左、右主支气管。 2. 鼻前庭是鼻腔的主要部分，由骨性鼻腔衬粘膜而成。 3. 蝶窦开口与上鼻道。 4. 环状软骨是喉软骨中惟一完整的软骨环，平对第 6 颈椎，是颈部重要的体表标志。 5. 声门裂是喉腔最狭窄的部位。 6. 喉腔向上通气管，向下和咽相交通。 7. 声襞是喉粘膜覆盖声韧带和声带肌而成。 8. 成年男性的喉结很明显，女性的喉结一般比男性略低。 9. 左主支气管较垂直，而右主支气管较水平，所以气管异物易落入右主支气管。 10. 两肺尖均高出锁骨外侧 1 / 3 的上方约 2 ～ 3cm 。 11. 胸膜腔呈负压状态。
无锡市数字城管呼叫中心系统技术方案 一、总体概述 呼叫中心设在无锡市数字化城管监督中心内，主要是通过电话形式接受社会公众举报，并对各类管理信息进行分析、分类、处理、立案、销案。 无锡市数字城管项目呼叫中心系统采用3个E1数字中继（90路）接入，ISDN信令；90路IVR，30个坐席，30路录音，支持H323、SIP协议。先期实现其中市局25个坐席，将来支持升级至VIOP模式接入8个分中心各配备8个人工坐席。 呼叫中心负责接听、录入市民举报现场信息和处置结果信息，对各类管理信息进行分析、分类、处理、立案、销案。 二、呼叫中心系统设计方案 2.1平台特性 2.1.1 设计先进 在硬件上，采用一体化设计，节省维护和扩展成本；在软件上采用分布式处理，以统一的接口协议进行通信，提高系统的处理能力和故障冗余能力，保证系统运行的稳定性。IVR和CTI服务器都可以进行双机热备，做到自动倒换，而实现所有的功能只需要性能适当的计算机而无需增加新的交换和语音设备。 系统在建成后一段时间内不会因技术落后而大规模调整，并能够通过升级保持系统的先进性；所采用的技术是稳定的、成熟的，支持现有的多种呼叫功能和网络协议。 2.1.2 支持多信令处理 系统具备SS7、SS1和ISDN PRI信令，支持H323和SIP VOIP技术，为用户呼叫中心组网提供多种信令方式。 2.1.3 支持多种媒体接入 提供集成语音、传真、IP、Web、E-mail等多种媒体接入的全面方案，用户能够灵活地通过电话、传真、Internet、E-mail等多种方式与业务代表进行交流，提高客户满意度。 (1) 支持Web方式接入 1
DESCRIPTION 13/190 46-FAD 104 08 Uen E Traffic Case Description - Mobile Originating Calls Abstract The purpose of this document is to describe the traffic case "Mobile Originating calls" from data transcript point of view. The document does not explain on BLOCK/SIGNAL level. This information can be found in the FUNCTION DESCRIPTION for each function block. All referenced DT sub files can be found in the DT Info Model. Contents 1 Revision information 1Revision information 2 Description 2.1Abbreviations 2.2Concepts 2.3Concerned nodes 2.4Prerequisites 2.5General 2.6Technical Solution 3 Traffic Case 3.1Call from MS/UE to PSTN 3.2Emergency Calls from MS/UE 4 Data Transcript Impacts- MSC 4.1AXE Parameters 5 Miscellaneous information 6 Class 7 References Revision Impacts Prepared Date A Document based on earlier CME20 DT Info Models.ERATHHE 96-09-13
音频制作步骤 我的音频作业制作的是五月天的《时光机》，通过录音、噪音采样、降低噪音、增加混响效果制作音频文件。 ⑴录制声音 录制声音之前需要连接好设备并调好音量，本次录音使用麦克风搭配手机录音。我使用的Cool Edit 2000是中文版。首先选择文件-新建菜单命令，创建一个新的声音文件，这时会出现新建波形对话框22050Hz、16位、单声道。如图1所示。 图1 新建文件对话框 在Cool Edit 2000中的左下部单击红色录音按钮，打开手机音频，开始录制声音。待录制时间长度为42秒后，单击停止按钮，此时波形显示区将出现刚录制好的文件波形图。若要播放，单击播放按钮。最后选择文件-保存菜单命令，将录制的声音存储到W A V文件中。 ⑵降低噪音 用放大工具调整波形大小。再利用鼠标选择声音的噪音部分，这时选择部分变白。样本应尽量采用声音波形振幅最小、最平直的噪音部分，一般为没有音乐信号的地方，这样可以包括最基本的噪音要素，更加利于提高准确性，如图2所示。 从效果菜单中选择噪音消除/降噪器命令，此时会弹出降噪器对话框。单击噪音采样按钮，几秒钟后系统会把噪音轮廓记录在噪音采样图形框中，如图3所示。在降噪器对话框中单击关闭按钮关闭对话框，注意不要按取消按钮来关闭对话框，回到系统的工作界面。 图2噪音采样
图3 降噪器对话框 使用水平缩放工具使整个声音波形都显示在波形显示区中，双击波形显示区选取整个波形。然后再次打开降噪器对话框，会看到噪音轮廓还在那里，这时按下OK按钮，系统就开始自动清除环境噪音。如果去除环境噪音后发现有用的话音也发生了变化，可以使用撤消工具取消降噪操作，然后把降噪器对话框中降噪级别滑块向低端移动少许，再进行降噪处理。 2.添加混响效果 从效果菜单中选择常用效果器/混响命令，此时屏幕上弹出混响对话框，如图4所示。
一、呼叫中心在企业中的定位： 呼叫中心定位的分类有许多种，以下的分类有助于我们更清楚地说明问题。前端——营销型呼叫中心： （1）电话销售-Telesales （2）电话覆盖—Telecoverage （3）电话机会管理—Teleprospecting 后端——服务支持型呼叫中心： （4）客户服务 （5）技术支持 对于后端支持型呼叫中心, 经理人的主要任务就是在最低成本内最大限度地提高客户满意度. 呼叫中心的主要衡量指标为话务相关的衡量, 也可将成本/话务量列入衡量指标, 但不应衡量单位获利. 有些后端支持呼叫中心也承担一些销售任务. 是不是呼叫中心的这种界限就应该被模糊呢? 一般说来, 在实施客户关系管理战略中, 不少企业将不同功能的呼叫中心整合在一起, 让客户面对一个电话号码, 一种服务标准(所谓contact center概念). 一个整体呼叫中心之所以能这样做是由于技术的发展使得这种整合成为可能. 但服务与销售需要完全不同的技能群组, 让同一组人掌握全部是不符合企业经济效益与个人潜能发展的. 所以即使是服务的销售也应由专门的电话销售团队去完成. 对于前端的营销型呼叫中心, 往往容易将其视为单独的利润中心. 一个至关紧要的事应该是如何将呼叫中心作为整个企业“Go-To-Market”(走向市场)
模式中的一个渠道. 除了电话销售有时可设计成利润中心外, 一般都不应强求. 包括呼叫中心在内的Go-To-Market模式可以包含这样一些渠道. ——面对面销售员 ——增值伙伴 ——分销商/经销商 ——零售店 ——电话营销 ——网络营销 ——其它直接营销 整个模式的最佳设计是应当根据产品, 客户, 地域等各方面因素制定出综合方案. 让呼叫中心“单兵作战”在目前的中国应该是不很适宜的. 如何设计包括呼叫中心/电话营销渠道在内的Go-To-Market模式是很多企业决策者与经理人必须掌握的一门基本功. 很多大型企业的呼叫中心还仅仅停留在后端服务型呼叫中心层次, 少数有着营销型呼叫中心的企业也往往只会用作销售线索的记录转发. 特别是一些依靠分销渠道的企业更会担心呼叫中心的营销一定会与分销渠道相冲突. 事实上, 根据我的经验, 中国的很多经销商非常欢迎企业的呼叫中心恰到好处地帮助他们做一些他们在自身范围内很难或不划算去做的事. 特别是当潜在客户刚开始在几家竞争厂商之间了解比价时就用呼叫中心帮助经销渠道迅速“抓住”而不是简单的“线索派发”. 此外, 呼叫中心的座席代表与实地销售代表也不应该是独立的团队而应是互相支持帮助, 一个衡量指标而责任有所侧重的团队. 中国惠普在过去的财年中通过呼叫中心(telesales)可测的销售收入近亿美元, 其实现包含了多种与其它销售渠道的合作方式.
学习-----好资料 呼叫中心培训流程 一、培训的目的： 1、通过呼叫中心服务人员的专业服务技巧来树立企业风范，正面提升企业的公众形象; 2、能够掌握呼叫中心服务沟通技巧，运用有效的沟通技巧与客户建立良好的沟通关系; 3、提升呼叫中心服务人员的整体素质，力求在行为细节上获得客户的认同; 4、能够正确处理客户投诉与客户抱怨的技巧 5、提升客户的服务质量，在服务礼仪中达到客户满意 二、培训的对象： 呼叫中心服务人员以及相关服务人员 三、培训大纲： 在当今市场竞争日趋激烈的形式下，由于产品和推广手段趋向于同质化，产品的利润空间不断下降，导致企业在不断的调整自己的市场策略，并将他们的关注点由自身的产品转向了客户，由自身的流程转向培养自己的服务能力，从而保证客户在每一次的购买过程和购买之后的体验中获得满意，并不断地超越其原有的期望值，这一经营策更多 精品文档． 学习-----好资料 略的转变将不断增强客户对企业的信任和忠诚，从而使企业获得长期赢利与可持续性发展，在竞争中取胜。
总体目标是使呼叫中心的服务人员掌握电话服务的特性，并提升电话 服务技巧，保证在与客户沟通和互动的过程中让客户满意，在处理客 户关系的棘手问题，如客户投诉的过程中转危为安，化被动为商机， 掌握永远赢得客户的有效方法。 四、工作程序 1、培训计划的编制 1.1编制的依据 1）公司方针目标和企业发展战略 2）人员与职能情况测定的结果和部门的培训需求 3）司员工完成其工作所需的技能知识 4）门体系运行中涉及的有关营销技巧和公司业务责任方面的专业知 识. 2、编制与审批 1）管理部在每月初根据部门上报的培训需求进行可行性的识别后,结 合培训依据,编制部门月培训计划报部门经理审批. 2）培训计划经过经理批准后,由部门负责下发营销部门 更多精品文档． 学习-----好资料 3）培训计划内容包括: 培训项目、对象、时间、人数、方式、课时、责任人、实施进度等. 4）培训计划实施过程中，应随培训需求情况的变化由营销部经理予
一次呼叫典型流程 B.1 概述 本节将分别给出主叫流程和被叫流程的例子，以示一次通话的典型流程。B.2 主叫流程 主叫流程是指UE呼叫其它用户（例如PSTN用户）的过程。具体流程如 图B-1所示，主叫流程大体经过了如下几个过程： (1) RRC连接建立 为了成功进行呼叫，UE将发起RRC连接建立过程，建立起与RNC之间的信 令连接。详细信息请参见错误！未找到引用源。错误！未找到引用源。描述。 (2) 信令连接建立 RNC建立起与CN之间的信令连接。详细信息请参见错误！未找到引用源。 错误！未找到引用源。描述。 (3) RAB建立 CN响应UE的业务请求，要求RNC建立相应的无线接入承载，建立成功后， 对方应答，双方通话。详细信息请参见错误！未找到引用源。错误！未找到 引用源。描述。 (4) 信令连接释放 通话过程结束，首先释放RNC和CN之间的信令连接。详细信息请参见错误！ 未找到引用源。错误！未找到引用源。描述。 (5) RAB释放 释放无线接入承载。详细信息请参见错误！未找到引用源。错误！未找到引 用源。描述。 (6) RRC释放 如果该RRC连接没有其他的IU信令连接，将释放UE和RNC之间的RRC 连接。详细信息请参见错误！未找到引用源。错误！未找到引用源。描述。
图B-1主叫流程
B.3 被叫流程 被叫流程是指网络侧有寻呼请求呼叫UE，UE响应寻呼的过程。UE接收到寻 呼消息后，将发起RRC连接建立过程。被叫流程大体经过如下几个过程： (1) 寻呼 网络侧寻呼UE。详细信息请参见错误！未找到引用源。错误！未找到引用源。 描述。 (2) RRC连接建立 UE应答呼叫，发起与RNC之间的RRC连接建立过程。详细信息请参见错误！ 未找到引用源。错误！未找到引用源。描述。 (3) 信令连接建立及直传过程 RNC建立起与CN之间的信令连接。详细信息请参见错误！未找到引用源。 错误！未找到引用源。描述； (4) RAB建立 CN要求RNC建立相应的无线接入承载。建立成功后，UE和CN交互信令， 应答进入通话状态。详细信息请参见错误！未找到引用源。错误！未找到引 用源。描述； (5) 信令连接释放 通话结束，释放RNC与CN之间的信令连接。详细信息请参见错误！未找到 引用源。错误！未找到引用源。描述； (6) RAB释放 释放无线接入承载。详细信息请参见错误！未找到引用源。错误！未找到引 用源。描述； (7) RRC释放 如果没有其他的无线接入承载，将释放UE与RNC之间的RRC连接。详细 信息请参见错误！未找到引用源。错误！未找到引用源。描述。 具体流程如图B-2所示。