3GPP2 C.S0055-A
Version 1.0
June 2008
Packet Switched Video Telephony Services (PSVT/MCS)
COPYRIGHT NOTICE
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 [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
3GPP2 C.S0055-A v1.0
No Text
ii 3GPP2 C.S0055-A v1.0
PREFACE
This document provides the service description for Packet Switched Video Telephony (PSVT) services operating over cdma2000 networks.
i 3GPP2 C.S0055-A v1.0
CONTENTS
Scope vii
1 Introduction...... 1
2 References...... 2 2.1 Normative References ...... 2 2.2 Informative References ...... 4
3 Definitions and Abbreviations...... 5 3.1 Abbreviations ...... 5
4 Overview (Informative)...... 6 4.1 Network Reference Model for PSVT...... 6 4.2 Network Reference Model for PSVT over IMS...... 8 4.3 RAN and PDSN Protocol Stacks...... 10 4.4 IP Protocol Stack...... 11
5 Call Signaling...... 13 5.1 Feature Initialization ...... 13 5.2 Call Origination and Reception (Informative)...... 14 5.2.1 Radio Bearer Establishment and SIP Signaling...... 14 5.3 Call Release (Informative) ...... 17 5.4 In-Call Media Management (Informative) ...... 19 5.4.1 Adding Bi-Directional Video to a VoIP Call...... 19 5.4.2 Removing Bi-Directional Video from a PSVT Call ...... 22 5.5 Session Description Protocol (SDP) Parameters (Informative)...... 25 5.5.1 SDP Offer ...... 25 5.5.2 SDP Answer ...... 26
6 Media...... 27 6.1 Codecs 27 6.1.1 Video ...... 27 6.1.2 Voice...... 27 6.2 Transport ...... 27 6.2.1 Header Compression...... 28 6.2.2 Media Synchronization...... 28
7 Quality of Service (QoS)...... 29 7.1 Radio Link QoS Configuration and Activation...... 29 7.1.1 Configuring QoS Reservations ...... 29 7.1.2 Activating QoS at Call Origination...... 31 7.1.3 Activating QoS at Call Answering ...... 32 7.1.4 QoS Adjustments at the Calling and Answering Terminals ...... 32
ii 3GPP2 C.S0055-A v1.0
8 Error Resiliency ...... 33 8.1 Packet and Picture Loss Indication...... 33 8.1.1 SDP Definitions ...... 33 8.1.2 Operation ...... 34 8.1.2.1 GNACK ...... 34 8.1.2.2 PLI ...... 34 8.1.3 Feedback Rate...... 34
9 Adaptation...... 35 9.1 Rate Adaptation Feedback Message...... 35 9.1.1 General Semantics for Using APTO_ARR Message...... 36 9.2 SDP Definitions ...... 36 9.2.1 SDP Offer ...... 37 9.2.2 SDP Answer ...... 37 9.2.3 Multiple Payload Types...... 40
10 Security and Encryption...... 41
11 PSVT Session Handling for HRPD to cdma2000 1xCS Domain Transfer ...... 42 11.1 PSVT terminal roles for registration in HRPD...... 42 11.2 PSVT terminal roles for Call Origination ...... 42 11.3 PSVT terminal roles during Call Termination ...... 42 11.4 PSVT terminal roles during Domain Transfer (DT) ...... 42 11.4.1 Releasing Video media of the ongoing PSVT session during DT...... 42 11.4.2 PSVT HRPD voice to cdma2000 1xCS voice DT...... 43
12 Annex A - QoS BLoB (Informative)...... 44
13 Annex B - Call Flow Examples for Supplementary Services and Functions (Informative)...... 51 13.1 PSVT Voice Retry...... 51 13.1.1 Retry PSVT Call Origination as VoIP...... 51 13.1.2 Retry PSVT Call Reception as VoIP ...... 53 13.1.3 Retry PSVT Call Origination as 1x Circuit-Switched Voice...... 56 13.1.4 Retry PSVT Call Reception as 1x Circuit-Switched Voice...... 57 13.2 Video/Media on Hold...... 60
14 ANNEX C - SDP Offer/Answer Examples for the b=AS and b=TIAS SDP Parameters (Informative) ...... 64
iii 3GPP2 C.S0055-A v1.0
LIST OF FIGURES
Figure 1 Network Reference Model for non-IMS Mobile-to-Mobile PSVT Call ...... 6
Figure 2 Network Reference Model for non-IMS Mobile-to-Internet Correspondent Node PSVT Call...... 7
Figure 3 Network Reference Model for Mobile-to-Mobile PSVT using IMS...... 8
Figure 4 Network Reference Model for Mobile-to-Internet Correspondent Node PSVT using IMS...... 9
Figure 5 Protocol Stack when HDLC framing is applied ...... 10
Figure 6 Protocol Stack when segment-based framing is applied ...... 11
Figure 7 PSVT Protocol Stacks over IP...... 12
Figure 8 Call Flow for PSVT Feature Initialization ...... 14
Figure 9 Call Origination and Reception for 3GPP2 PSVT Terminals ...... 15
Figure 10 Call Release for 3GPP2 PSVT Terminals ...... 18
Figure 11 Call Flow for Adding Video to VoIP Call...... 20
Figure 12 Call Flow for User-Initiated Removal of Video Stream from PSVT Call...... 22
Figure 13 Call Flow for Network-Initiated Removal of Video Stream from PSVT Call ...... 24
Figure 14 Call Flow for Retry PSVT Call Origination as VoIP ...... 52
Figure 15 Call Flow for Retry PSVT Call Reception as VoIP ...... 54
Figure 16 Call Flow for Retry PSVT Call Origination as 1x CS Voice ...... 56
Figure 17 Call Flow for Retry PSVT Call Reception as 1x CS Voice ...... 58
Figure 18 Call Flow for Video on Hold Feature...... 61
iv 3GPP2 C.S0055-A v1.0
LIST OF TABLES
Table 1 QoS Reservations for Multiple QoS_ATTRIBUTE_SETs ...... 30
Table 2 Allowable setting of “apto-arr”
Table 3 Example of Request QoS BLoB...... 49
v 3GPP2 C.S0055-A v1.0
FOREWORD
(This foreword is not part of this Standard.)
The potential benefits of communicating via visual media, in addition to voice, have long been recognized as greatly enhancing the potential for users to communicate and to convey information. Video telephony allows users to simultaneously send and receive voice and video images in real time. Video images may be captured by a local camera or previously stored locally for retrieval and transmission to the far end user. Visual images may be a sequence of video frames simulating smooth motion or intermittent still images, both photographic and graphical. A user can stop video communication without interrupting the voice conversation.
Transmitting a video stream has proven to be a very challenging goal, since it requires significant resources, and therefore can place a heavy burden on the system. Because a video stream contains much more information than voice alone, it demands a much higher data rate. In order to reduce the data rate, many video codecs are optimized for maximum compression alone, and thus are sensitive to transmission errors.
With the development of 3G wireless communications systems, the data rate available to each user can be considerably increased. The available network throughput has reached the threshold where reasonable quality video telephony services can be realized.
As of late, new developments in packet (IP based) networks have made video telephony a more viable service due, in part, to the following:
Standardization of comprehensive QoS capabilities in all variants of cdma2000®1 wireless networks;
Payload flexibility of packet switching and routing, which enables asymmetric and variable rate bearers;
Optimization of wireline protocols for wireless networks (e.g. protocol header compression/removal);
Increase in number of devices (PCs and laptop computers) frequently attached to a network (wide area wireless, WLAN, or wired), in addition to the camera-equipped wireless phones.
1 cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
vi 3GPP2 C.S0055-A v1.0
SCOPE
This document specifies the end-to-end protocols and procedures for support of Packet Switched Video Telephony (PSVT) Services over cdma2000 networks. This document defines the end-to-end PSVT service and architecture. The Stage 1 requirements for the PSVT Service are specified in [42]. The end-to-end system design is described in [43].
PSVT provides support of one-to-one conversational video services between a PSVT Terminal and another PSVT Terminal or a video terminal on the Internet. The procedures specified in this document are based upon procedures in [1][2][3][4][6][7][8][9][10][12][13][17][18][19]. If there is a conflict between the procedures in this document and those in the above referenced standards, the procedures in the referenced standards take precedence.
In this document, several key words are used to signify the requirements. The key words “shall”, “shall not”, “should”, “should not” and “may” are to be interpreted as described in [20] and the TIA Engineering Style Manual.
vii 3GPP2 C.S0055-A v1.0
1 2 3 No Text 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
viii 3GPP2 C.S0055-A v1.0
1 2 3 1 Introduction 4 5 A PSVT call involves call signaling and media transmission. For a successful PSVT call, call signaling includes 6 locating the callee, notifying the callee that a caller would like to initiate a PSVT call, acceptance by the callee, 7 and capabilities exchange. Media transmission requires the encoding of video, voice, and other media for 8 transmission over a packet switched transport network. Encoding, especially in the case of video and usually for 9 voice, often involves considerable compression (often lossy). To aid in the transmission of these compressed 10 media streams, a predefined transmission format (e.g., RTP) is used. The receiving terminal must reconstruct 11 the media streams from the incoming packets (which may be missing or out of order) and decode them. 12 Typically, a terminal is encoding and decoding simultaneously. 13 14 15 The signaling protocols and encoding methods presented in this specification were selected to make the best 16 possible use of the capabilities inherent in CDMA2000 networks while providing a high degree of 17 interoperability with other networks. In no case is full interoperability precluded for those systems that include 18 the additional signaling and codecs necessary to do so. Existing, well established technologies were chosen to 19 ensure broad-based support. In anticipation of continued advancements in terminal capabilities, advanced 20 technologies are supported as well. Additionally, the signaling methods utilized are extensible without revision 21 of this specification or those it references. 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
1 3GPP2 C.S0055-A v1.0
1 2 3 4 2 References 5 6 The following documents contain provisions, which, through reference in this text, 7 constitute provisions of this document. 8 9 References are either specific (identified by date of publication, edition number, 10 version number, etc.) or non-specific. 11 For a specific reference, subsequent revisions do not apply. 12 13 For a non-specific reference, the latest version applies. In the case of a reference to a 14 3GPP2 document, a non-specific reference implicitly refers to the latest version of 15 that document in the same Release as the present document. 16 17 18 19 20 2.1 Normative References 21 22 23 [1] 3GPP2: A.S0008-B v1.0, Interoperability Specification (IOS) for High Rate Packet 24 Data (HRPD) Radio Access Network Interfaces With Session Control in the Access 25 Network, October 2006. 26 27 [2] 3GPP2: A.S0009-B v1.0, Interoperability Specification (IOS) for High Rate Packet 28 Data (HRPD) Radio Access Network Interfaces With Session Control in the Packet 29 Control Function, October 2006. 30 31 [3] 3GPP2: A.S0013-C, Interoperability Specification (IOS) for cdma2000 Access 32 Network Interfaces – Part 3 Features, January 2006. 33 34 35 [4] 3GPP2: A.S0014-C, Interoperability Specification (IOS) for cdma2000 Access 36 Network Interfaces – Part 4 (A1, A1p, A2, and A5 Interfaces), January 2006. 37 38 [5] Void. 39 40 [6] 3GPP2: C.S0001-A v5.0, Introduction for cdma2000 Spread Spectrum Systems, July 41 2001. 42 43 44 [7] 3GPP2: C.S0002-A v6.0, Physical Layer Standard for cdma2000 Spread Spectrum 45 Systems, February 2002. 46 47 [8] 3GPP2: C.S0003-A v6.0, Medium Access Control (MAC) Standard for cdma2000 48 Spread Spectrum Systems, February 2002. 49 50 51 [9] 3GPP2: C.S0004-A v6.0, Signaling Link Access Control (LAC) Standard for 52 cdma2000 Spread Spectrum Systems, February 2002. 53 54 [10] 3GPP2: C.S0005-A v6.0, Upper Layer (Layer 3) Signaling Standard for cdma2000 55 Spread Spectrum Systems, February 2002. 56 57 [11] 3GPP2: C.S0014-C, Enhanced Variable Rate Codec, Speech Service Options 3, 68, 58 and 70 for Wideband Spread Spectrum Digital Systems, February 2007. 59 60
2 3GPP2 C.S0055-A v1.0
1 [12] 3GPP2: C.S0017-012-A v1.0, Data Service Options for Spread Spectrum Systems: 2 Service Options 33 and 66, July 2004. 3 4 5 [13] 3GPP2: C.S0024-A v1.0, cdma2000 High Rate Packet Data Air Interface 6 Specification, April 2004. 7 8 [14] Void. 9 10 [15] Void. 11 12 13 [16] Void. 14 15 [17] 3GPP2: X.S0011-D v1.0 cdma2000 Wireless IP Network Standards (Parts 001-006), 16 February 2006. 17 18 [18] 3GPP2: X.S0013-002-A v1.0, All-IP Core Network Multimedia Domain: IP Multimedia 19 Subsystem – Stage 2, November 2005. 20 21 22 [19] 3GPP2: X.S0013-004-A v1.0, All-IP Core Network Multimedia Domain: IP Multimedia 23 Call Control Protocol Based on SIP and SDP – Stage 3, November, 2005. 24 25 [20] IETF: RFC 2119, Bradner, ‘Key words for use in RFCs to Indicate Requirement 26 Levels’, March 1997. 27 28 [21] IETF: RFC 3016, Y. Kikuchi, et al, "RTP Payload Format for MPEG-4 Audio/Visual 29 Streams", November 2000. 30 31 32 [22] IETF: RFC 3095, Borman, et al, ‘RObust Header Compression (ROHC): Framework 33 and four profiles: RTP, UDP, ESP, and uncompressed’, July 2001. 34 35 [23] IETF: RFC 3261, J. Rosenberg et al, ‘SIP: Session Initiation Protocol’, June 2002. 36 37 [24] IETF: RFC 3264, Rosenberg and Schulzrinne, ‘An Offer/Answer Model with the 38 39 Session Description Protocol (SDP)’, June 2002. 40 41 [25] IETF: RFC 3388, Camarillo, et al, ‘Grouping of Media lines in the Session Description 42 Protocol (SDP)’, December 2002. 43 44 [26] IETF: RFC 3550, Schulzrinne, et al. ‘RTP: A Transport Protocol for Real-Time 45 Applications’, July 2003. 46 47 48 [27] IETF: RFC 3551, Schulzrinne, et al. ‘RTP Profile for Audio and Video Conferences 49 with Minimal Control’, July 2003. 50 51 [28] IETF: RFC 3556, S. Casner, ‘Session Description Protocol (SDP) Bandwidth 52 Modifiers for RTP Control Protocol (RTCP) Bandwidth’, July 2003. 53 54 [29] IETF: RFC 3890, M. Westerlund, ‘A Transport Independent Bandwidth Modifier for 55 the Session Description Protocol (SDP)’, September 2004. 56 57 58 [30] IETF: RFC 3984, S. Wenger, et al, ’RTP Payload Format for H.264 Video,' February 59 2005. 60
3
3GPP2 C.S0055-A v1.0
1 2 [31] IETF: RFC 4234, D. Crocket, et al, ’Augmented BNF for Syntax Specifications: 3 ABNF’, October 2005. 4 5 6 [32] IETF: RFC 4566, M. Handley et al, ‘SDP: Session Description Protocol’, July 2006. 7 8 [33] IETF: RFC 4585, J. Ott, et al, ’Extended RTP Profile for Real-time Transport Control 9 Protocol (RTCP) – Based Feedback (RTP/AVPF)’, July 2006. 10 11 [34] IETF: RFC 4629, J. Ott et. al., ‘RTP Payload Format for ITU-T Rec. H.263 Video,’ 12 January 2007 13 14 15 [35] IETF: RFC 4788, Q. Xie and R. Kapoor, ‘Enhancements to RTP Payload Formats for 16 EVRC Family Codecs,’ January 2007. 17 18 [36] 3GPP2: X.S0042-0, Voice Call Continuity between IMS and Circuit Switched 19 Systems 20 21 [37] IETF: RFC 5188, H.Desineni and Q.Xie, ‘RTP Payload Format for the Enhanced 22 Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for 23 24 EVRC-B Codec’ 25 26 [38] 3GPP: TS 26.114 ver7.3.1 “IMS; Multimedia Telephony; Media handling and 27 interaction.” 28 29 [39] IETF: draft-ietf-mmusic-sdp-capability-negotiation-08.txt, ‘SDP capability negotiation’, 30 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-08.txt 31 32 33 Editor's Note: The above document is a work in progress and should not be referenced unless and until it is 34 approved and published. Until such time as this Editor’s Note is removed, the inclusion of the above document 35 is for informational purposes only. 36 37 2.2 Informative References 38 39 40 [40] 3GPP2: C.R1001-E v1.0, Administration of Parameter Value Assignments for 41 cdma2000 Spread Spectrum Standards, October 2005. 42 43 [41] 3GPP2: S.R0086-A, IMS Security Framework, June 2004. 44 45 [42] 3GPP2: S.R0106-0 v1.0, Packet Switched Video Telephony – Stage 1, August 2005. 46 47 48 [43] 3GPP2: X.R0039-0 v1.0, Packet Switched Voice (over IP) and Video Telephony 49 Services; End-to-end System Design Technical Report, April 2006. 50 51 52 53 54 55 56 57 58 59 60
4 3GPP2 C.S0055-A v1.0
1 2 3 3 Definitions and Abbreviations 4 5 This section contains definitions, symbols and abbreviations that are used throughout 6 the document. 7 8 9 3.1 Abbreviations 10 11 1X cdma2000 1x air interface as specified in [6][7][8][9][10] 12 rd 13 3GPP 3 Generation Partnership Project 14 3GPP2 3rd Generation Partnership Project 2 15 16 AAA Authentication, Authorization, and Accounting 17 AS Application Server 18 AES Advanced Encryption Standard 19 20 AN Access Network 21 AT Access Terminal 22 23 BSC Base Station Controller 24 CN Core Network 25 CS Circuit Switched 26 27 DT Domain Transfer 28 H-AAA Home AAA 29 30 HDLC High-level Data Link Control 31 HRPD High Rate Packet Data 32 IMS IP Multimedia Subsystem 33 34 IP Internet Protocol 35 PDSN Packet Data Serving Node 36 37 PPP Point to Point Protocol 38 PSVT Packet Switched Video Telephony 39 40 RADIUS Remote Authentication Dial In User Service 41 RAN Radio Access Network 42 RLP Radio Link Protocol 43 44 ROHC Robust Header Compression 45 RTCP Real-time Transport Control Protocol 46 47 RTP Real-time Transport Protocol 48 SDP Session Description Protocol 49 SIP Session Initiation Protocol [23] 50 51 UDP User Datagram Protocol 52 UE User Equipment 53 54 UIM User Identity Module 55 VCC Voice Call Continuity 56 57 58 59 60
5
3GPP2 C.S0055-A v1.0
1 2 3 4 4 Overview (Informative) 5 6 The following section gives an overview of the network reference models and protocol stacks used to provide 7 the PSVT service over the 3GPP2 IMS and non-IMS networks operating over cdma2000 radio access networks. 8 9 10 4.1 Network Reference Model for PSVT 11 12 The network reference model for a mobile-to-mobile PSVT call is illustrated in Figure 1. 13 14 15 16 17 18 19 SIP Proxy SIP Proxy 20 21 22 AAA 23 AAA 24 25 26 Network A IP Network B Networks 27 28 29 30 PSVT 31 PSVT RAN PDSN Terminal PDSN RAN Terminal 32 33 34 35 36 SIP Signaling 37 Air Interface/IOS Signaling 38 Media Control for Audio/Video PSVT /VoIP Audio Bearer Path 39 PSVT Video Bearer Path 40 AAA Interface 41 42 43 44 45 Figure 1 Network Reference Model for non-IMS Mobile-to-Mobile PSVT Call 46 47 48 The function of each entity is listed below: 49 AAA 50 51 The AAA authenticates the subscriber to the access network and sends the list of the subscriber’s 52 authorized QoS Profile IDs to the RAN via the PDSN, including the QoS Profile IDs for PSVT. The 53 AAA also performs the accounting for the access network. 54 PDSN 55 56 The PDSN communicates with the PSVT Terminal using service connections for packet data session 57 establishment, to add and remove IP flows, etc. as described in [17]. The PDSN function acts as the 58 first-hop router for IP traffic to and from the PSVT Terminal. 59 60 PSVT Terminal
6 3GPP2 C.S0055-A v1.0
1 The PSVT Terminal is a 3GPP2 access terminal that adheres to the requirements in this specification. 2 The PSVT Terminal contains the video and audio codecs that provide the multimedia interface to the 3 user. The PSVT Terminal also contains the SIP user agent that communicates with the other terminal 4 (PSVT Terminal or general IP video telephony device) through an IP core network. 5 6 RAN 7 8 The Radio Access Network communicates with the PSVT Terminal using the service option [12] or 9 link flow [13] to transport packet data over the radio link. 10 SIP Proxy 11 12 Serves as a SIP proxy [23] that accepts requests and services them internally or forwards them on to 13 the PSVT Terminal or the peer SIP Proxy of the other PSVT Terminal. 14 15 The network reference model for a mobile-to-correspondent-node PSVT call is illustrated in Figure 2. 16 17 18 19 20 21 22 23 24 SIP Proxy SIP Proxy 25 26 27 28 AAA 29 30 IP 31 Networks 32 (Internet) 33 34 Corres- 35 PSVT RAN PDSN Terminal pondent 36 Node 37 38 39 40 Network A 41 SIP Signaling 42 Air interface/IOS Signaling 43 Media Control for Audio/Video 44 PSVT /VoIP Audio Bearer Path 45 PSVT Video Bearer Path AAA Interface 46 47 48 49 50 Figure 2 Network Reference Model for non-IMS Mobile-to-Internet Correspondent Node PSVT 51 Call 52 53 Corespondent Node 54 The Correspondent Node is a packet switched video terminal on the Internet. 55 56 57 58 59 60
7
3GPP2 C.S0055-A v1.0
1 2 3 4.2 Network Reference Model for PSVT over IMS 4 5 6 The network reference model for a mobile-to-mobile PSVT over IMS call is illustrated in Figure 3. 7 8 AS AS 9 (optional) (optional) 10 11 12 HSS I/S-CSCF I/S-CSCF HSS 13 14 15 16 AAA 17 AAA 18 P-CSCF P-CSCF MRFC 19 Network A (optional) IP Network B 20 Networks 21 22 23 24 PSVT RAN PDSN PSVT 25 Terminal PDSN RAN Terminal 26 MRFP (optional) 27 28 29 SIP Signaling 30 Air Interface/IOS Signaling 31 Media Control for Audio/Video 32 PSVT /VoIP Audio Bearer Path 33 PSVT Video Bearer Path 34 AAA/HSS Interfaces MP Interfaces 35 36 37 38 39 Figure 3 Network Reference Model for Mobile-to-Mobile PSVT using IMS 40 41 The function of each entity is listed below: 42 43 AS 44 The Application Server can be a SIP application server (e.g., video mail or voice mail server, etc…) as 45 specified in [18] and [19] or an OSA gateway as specified in [18]. 46 47 48 HSS 49 The HSS provides the authentication vector to the S-CSCF for IMS authentication. The HSS also 50 performs authorization and accounting for the IMS. 51 52 I-CSCF 53 Interrogating-CSCF (I-CSCF) is the entry point within an operator’s network for all connections 54 55 destined to a user of that network operator, or a roaming user currently located within that network 56 operator’s service area. 57 P-CSCF 58 59 60
8 3GPP2 C.S0055-A v1.0
1 The Proxy-CSCF is the first contact point within the IP Multimedia Subsystem [18]. The P-CSCF 2 behaves like a Proxy, i.e. it accepts requests and services them internally or forwards them on to the 3 PSVT Terminal, an I-CSCF, or the S-CSCF. 4 5 MRFC 6 The Media Resource Function Controller, in conjunction with the MRFP, provides a set of resources 7 with the MMD core network that are useful in supporting services to subscribers. In the network 8 reference model the MRFC interfaces to the S-CSCF to determine media conversion requirements and 9 instructs the MRFP to perform any necessary conversion of the media stream. 10 11 12 MRFP 13 The Media Resource Function Processor converts the media formats sent between the PSVT Terminals 14 when the PSVT Terminals use incompatible codecs. 15 16 17 S-CSCF 18 19 The Serving-CSCF (S-CSCF) performs the session control services for the PSVT Terminal. It 20 maintains a session state as needed by the network operator for support of the services. 21 22 The network reference model for a mobile-to-correspondent-node PSVT using IMS for call control is illustrated 23 in Figure 4. 24 25 26 27 28 AS 29 (optional) 30 31 32 HSS I/S-CSCF SIP Proxy 33 34 35 36 AAA MRFC P-CSCF 37 (optional) 38 IP 39 Networks (Internet) 40 41 42 Corres- PSVT 43 RAN PDSN pondent Terminal 44 MRFP Node 45 (optional) 46 47 48 Network A 49 SIP Signaling Air interface/IOS Signaling 50 Media Control for Audio/Video 51 PSVT /VoIP Audio Bearer Path 52 PSVT Video Bearer Path 53 AAA/HSS Interfaces 54 MP Interfaces 55 56 57 Figure 4 Network Reference Model for Mobile-to-Internet Correspondent Node PSVT using IMS 58 59 60
9
3GPP2 C.S0055-A v1.0
1 2 3 4.3 RAN and PDSN Protocol Stacks 4 5 The PSVT service defined in this specification can operate over these and future network protocols that support 6 transport of IP traffic. 7 8 Figure 5 illustrates the protocol stack for the PSVT Terminal, Radio Access Network, and PDSN when HDLC 9 framing is used between the PDSN and PSVT Terminal to frame IP packets. For 1X this illustrates service 10 option 331[12] or 66 [12] over the air interface. For HRPD this illustrates service option 592 [13] or 64 [13]. 11 12 13 PSVT RAN PDSN 14 Terminal 15 16 17 18 IP IP IP IP 19 20 21 PPP Encapsulation PPP 22 23 HDLC Framing HDLC 24 L2 25 RLP RLP 26 27 R-P R-P 28 Mux Mux 29 30 Physical 31 Physical Layer L1 L1 L1 Layer 32 33 34 35 36 Figure 5 Protocol Stack when HDLC framing is applied 37 38 Figure 6 illustrates the protocol stack for the PSVT Terminal, Radio Access Network, and PDSN when 39 segment-based framing is used between the Radio Access Network and the PSVT Terminal to frame IP packets. 40 For HRPD, segment based framing is performed as a sublayer in the RLP layer. This illustrates service option 41 67 [13] for HRPD. 42 43 44 45 46 47 48 49 50 51 52 53 54 55
56 57 1 58 Service Option 33 (main service option) can be used to transport SIP signalling over 1X. 59 2 60 Service Option 59 (main service option) can be used to transport SIP signalling over HRPD.
10 3GPP2 C.S0055-A v1.0
1 2 PSVT 3 RAN PDSN Terminal 4 5 6 7 8 IP IP 9 10 Segment Segment Framing 11 Framing 12 13 RLP RLP 14 R-P R-P L2 15 16 17 18 Mux Mux 19 20 21 Physical Layer Physical Layer L1 L1 L1 22 23 24 25 Figure 6 Protocol Stack when segment-based framing is applied 26 27 28 4.4 IP Protocol Stack 29 30 Control and media traffic flows1 are carried over the IP protocol. They have different protocol stacks and may 31 32 travel through different paths, as illustrated in Figure 7. 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 1 Control traffic flow includes session/call control traffic (SIP/UDP or SIP/TCP) and media control (RTCP/UDP). Media traffic flow refers 59 to RTP/UDP traffic. 60
11
3GPP2 C.S0055-A v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
39 40 41 Figure 7 PSVT Protocol Stacks over IP 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
12 3GPP2 C.S0055-A v1.0
1 2 3 5 Call Signaling 4 5 The following procedures and call flows illustrate the operation between an originating PSVT Terminal 6 attached to a cdma2000 access network and a terminating PSVT Terminal attached to a cdma2000 access 7 network. Interoperability with other types of terminals or terminals on other types of networks is outside the 8 scope of this specification. 9 10 In all the call flows in this section the following applies: 11 12 13 • For PSVT using IMS for call control, both PSVT Terminal 1 and PSVT Terminal 2 are supported by 14 an IMS core network [19] that is comprised of a P-CSCF, S-CSCF, I-CSCF, and AS. IMS CN 15 represents the IMS core network supporting PSVT Terminal 1 and the IMS core network supporting 16 PSVT Terminal 2. Note that the IMS core network supporting PSVT Terminal 1 may or may not be 17 the same IMS core network supporting PSVT Terminal 2. 18 19 • For PSVT not using IMS for call control, the IMS CN refers to the collection of SIP proxies used to 20 connect PSVT Terminal 1 to PSVT Terminal 2. 21 22 5.1 Feature Initialization 23 24 25 When the PSVT feature has been activated by the user (i.e., prior to originating or receiving any PSVT calls) 26 and the PSVT Terminal is attached to a cdma2000 access network the PSVT Terminal shall perform (in no 27 particular order) the following procedures: 28 29 • Configure and activate QoS for transporting SIP traffic (SIP flow). See section 7.1.1. 30 31 32 • Configure QoS for transporting voice traffic (voice flow). See section 7.1.1. 33 34 • Configure QoS for transporting video traffic (video flow). See section 7.1.1. 35 36 • Configure QoS for transporting RTCP packets for both the voice and video streams. The RTCP traffic 37 may be transported over the flow activated for SIP traffic or over separately reserved QoS flows. See 38 section 7.1.1. 39 40 • Negotiate ROHC parameters for compressing the voice and video traffic if the PSVT Terminal 41 supports ROHC. See [13]. 42 43 To reduce feature initialization time, the PSVT Terminal may perform the above procedures simultaneously. 44 The PSVT Terminal shall then register with the SIP Register [23] or a S-CSCF [19]. These procedures are 45 illustrated in Figure 8. 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
13
3GPP2 C.S0055-A v1.0
1 2 3 PSVT RAN/ IMS Core Network 4 Terminal PDSN 5 6 7 8 CONFIGURE AND ACTIVATE QoS for SIP flow 9 10 11 12 13 14 CONFIGURE QoS for voice flow 15 16 17 18 MAY BE 19 CONFIGURE QoS for video flow 20 SIMULTANEOUS 21 22 23 24 CONFIGURE QoS for voice and video 25 RTCP traffic flows 26 27 28 29 30 ROHC NEGOTIATION 31 32 33 34 35 36 IMS/SIP REGISTRATION 37 38 39 40 41 42 Figure 8 Call Flow for PSVT Feature Initialization 43 44 45 5.2 Call Origination and Reception (Informative) 46 47 This section uses the call flow in Figure 9 to describe typical procedures for originating and receiving a PSVT 48 call. The expected behavior of an originating (calling) PSVT Terminal is described for PSVT Terminal 1 and 49 the expected behavior for a receiving (called) PSVT Terminal is described for PSVT Terminal 2. 50 51 52 5.2.1 Radio Bearer Establishment and SIP Signaling 53 54 Step 1 55 56 The originating PSVT Terminal activates its QoS reservations (section 7.1.2) for the voice and video flows 57 before initiating the PSVT call. 58 59 60
14 3GPP2 C.S0055-A v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 Figure 9 Call Origination and Reception for 3GPP2 PSVT Terminals 47 48 Step 2 49 50 After QoS activation in step 1, PSVT Terminal constructs a SIP INVITE request and sends this to the P-CSCF 51 supporting PSVT Terminal 1. The SDP parameters included in the SIP INVITE are specified in section 5.5.1. 52 53 Step 3 54 55 56 The P-CSCF sends a 100 Trying response to the INVITE. The IMS CN performs processing of the INVITE 57 request and routes it to PSVT Terminal 2. The S-CSCFs in either CN and/or application servers in the request 58 path might perform service/call control. 59 60
15
3GPP2 C.S0055-A v1.0
1 2 Upon receiving the SIP INVITE, PSVT Terminal 2 sends a 100 trying response to the P-CSCF. 3 4 Step 4 5 6 Upon receiving the INVITE request, PSVT Terminal 2 activates the QoS reservations for the voice and video 7 flows that are required to support the media codecs selected by PSVT Terminal 2. 8 9 10 Step 5 11 12 Since the resource reservation on both sides is complete, PSVT Terminal 2 constructs a 180 Ringing response 13 consisting of an SDP answer and sends this reliably to the P-CSCF of PSVT Terminal 2. The SDP parameters 14 to be included in the SDP answer are specified in section 5.5.2. PSVT Terminal 2 is ready to receive media at 15 this time. 16 17 Step 6 18 19 The IMS CN performs processing of the 180 Ringing response and routes it to PSVT Terminal 1. The S-CSCFs 20 in either CN and/or application servers in the response path might perform service/call control. 21 22 Step 7 23 24 Upon receiving the 180 Ringing response PSVT Terminal 1 plays a ringtone (ringback) locally. 25 26 27 Step 8 28 29 If the INVITE in step 2 contained a Supported header field with the option tag “100rel” and if the 180 Ringing 30 in Step 6 contained a Require header with the tag “100rel” then PSVT Terminal 1 sends a PRACK request to 31 acknowledge the reliable 180 Ringing response. 32 33 Step 9 34 35 The IMS CN forwards the PRACK request to PSVT Terminal 2. 36 37 Step 10 38 39 PSVT Terminal 2 matches the PRACK to the reliable 180 Ringing response. PSVT Terminal 2 alerts the called 40 party of the incoming call. 41 42 43 Step 11 44 45 Since the PRACK matched a reliable provisional response, PSVT Terminal 2 responds with a 200 OK. 46 47 Step 12 48 49 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. 50 51 Step 13 52 53 The called party answers the phone. 54 55 Step 14 56 57 58 When the called party answers, PSVT Terminal 2 sends a 200 OK final response for the INVITE transaction. 59 PSVT Terminal 2 may begin sending media at this time. 60
16 3GPP2 C.S0055-A v1.0
1 Step 15 2 3 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. PSVT Terminal 1 may begin sending 4 media after receiving the 200 OK response. 5 6 7 Step 16 8 9 PSVT Terminal 1 sends ACK request to acknowledge the 200 OK. 10 11 Step 17 12 13 The IMS CN forwards the ACK to PSVT Terminal 2. 14 15 Step 18 16 17 PSVT Terminal 1 and PSVT Terminal 2 exchange bidirectional RTP voice and video using the negotiated 18 codecs. This does not begin any earlier than after steps 14 and 15 as described above. 19 20 21 5.3 Call Release (Informative) 22 23 This section uses the call flow in Figure 10 to describe the procedures for releasing a PSVT call. The expected 24 behavior of a PSVT Terminal initiating the call release is specified for PSVT Terminal 1 and the expected 25 behavior for a PSVT Terminal responding to the call release is specified for PSVT Terminal 2. 26 27 28 Step 1 29 30 The two terminals are involved in a PSVT call and are actively exchanging RTP voice and video media. 31 32 Step 2 33 34 Either party in the PSVT session can initiate a call release by sending a BYE message. In the following call 35 flows the subscriber at PSVT Terminal 1 hangs-up. 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
17
3GPP2 C.S0055-A v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Figure 10 Call Release for 3GPP2 PSVT Terminals 29 30 Step 3 31 32 PSVT Terminal 1 constructs a SIP BYE request and sent it to its P-CSCF in the IMS CN. PSVT Terminal 1 33 immediately stops listening on its codecs and stops sending more data. 34 35 Step 4 36 37 The IMS CN forwards the BYE request to PSVT Terminal 2. 38 39 Step 5 40 41 42 PSVT Terminal 1 deactivates its QoS for the voice and video flows after one of the following events: 43 44 • Expiration of an implementation-dependent timer started after sending the BYE request, or 45 46 • After receiving the 200 OK response. 47 48 Step 6 49 50 PSVT Terminal 2 responds to the BYE with a 200 OK response. 51 52 Step 7 53 54 If its QoS reservation is still active upon sending the 200 OK response, PSVT Terminal 2 deactivates its QoS 55 56 reservation after an implementation-dependent time. 57 58 Step 8 59 60 The IMS CN forwards the 200 OK to PSVT Terminal 1.
18 3GPP2 C.S0055-A v1.0
1 2 5.4 In-Call Media Management (Informative) 3 4 The following procedures define how media is added or removed from an active VoIP/PSVT call. 5 6 5.4.1 Adding Bi-Directional Video to a VoIP Call 7 8 9 The following section describes how a PSVT call is established when adding bi-directional video media to an 10 existing VoIP call (Figure 11). 11 12 Step 1 13 14 The two terminals are involved in a VoIP call and are actively exchanging RTP voice media. 15 16 Step 2 17 18 19 The user of PSVT Terminal 1 decides to change the call in to a PSVT call. 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
19
3GPP2 C.S0055-A v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
45 46 47 Figure 11 Call Flow for Adding Video to VoIP Call 48 49 Step 3 50 51 PSVT Terminal 1 activates its QoS reservation for the video flow before initiating the transition to a PSVT call 52 with PSVT Terminal 2. 53 54 Step 4 55 56 After the QoS activation in Step 3, PSVT Terminal 1 constructs a SIP re-INVITE request and sends this to the 57 P-CSCF of PSVT Terminal 1. The SDP parameters to be included in the SIP INVITE contain a video media 58 line (m=) and the other parameters specified in section 5.5.1. PSVT Terminal 1 continues to use the same audio 59 media (m=) line from the previously negotiated SDP to prevent interruption in the voice media decoding. 60
20 3GPP2 C.S0055-A v1.0
1 Step 5 2 3 The P-CSCF sends a 100 Trying response to the re-INVITE. The IMS CN performs processing of the re- 4 INVITE request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. 5 6 7 Upon receiving the SIP re-INVITE, PSVT Terminal 2 immediately sends a 100 trying response to suppress 8 retransmissions of the re-INVITE by the P-CSCF. 9 10 Step 6 11 12 Upon receiving the re-INVITE request PSVT Terminal 2 activates the QoS reservation for the video flow that is 13 required to support the video codec selected by PSVT Terminal 2. 14 15 Step 7 16 17 PSVT Terminal 2 asks its user whether to add a video flow to the VoIP call. 18 19 Step 8 20 21 The user of Terminal 2 agrees to add video. 22 23 24 Step 9 25 26 PSVT Terminal 2 responds with a 200 OK that contains the SDP Answer parameters specified in 5.5.2. PSVT 27 Terminal 2 is ready to receive video media at this time. 28 29 Step 10 30 31 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. After receiving the 200 OK response 32 PSVT Terminal 1 is ready to receive video media and may begin sending video media. 33 34 When PSVT Terminal 1 starts sending video media it immediately sends an RTCP Sender Report for the video 35 media to PSVT Terminal 2. This will allow PSVT Terminal 2 to quickly synchronize the received video stream 36 with the voice stream. 37 38 Step 11 39 40 41 PSVT Terminal 1 sends ACK request to acknowledge the 200 OK. 42 43 Step 12 44 45 The IMS CN forwards the ACK to PSVT Terminal 2. PSVT Terminal 2 may begin sending video media after 46 receiving the ACK. 47 48 When PSVT Terminal 2 starts sending video media it immediately sends RTCP Sender Reports for both the 49 video and voice media to PSVT Terminal 1. This allows PSVT Terminal 1 to quickly synchronize the received 50 video stream with the voice stream. PSVT Terminal 1 also sends RTCP Sender Reports for both the video and 51 voice media when PSVT Terminal 1 starts sending video media to PSVT Terminal 2. 52 53 Step 13 54 55 PSVT Terminal 1 and PSVT Terminal 2 exchange bidirectional RTP voice and video using the negotiated 56 57 codecs. 58 59 60
21
3GPP2 C.S0055-A v1.0
1 2 5.4.2 Removing Bi-Directional Video from a PSVT Call 3 4 5 5.4.2.1 User-Initiated Removal of Video from a PSVT Call 6 7 The following section describes how bi-directional video media is removed from an existing PSVT call (Figure 8 12) when the user of PSVT Terminal 1 initiates the video removal. 9 10 Step 1 11 12 13 The two terminals are involved in a PSVT call and are actively exchanging bi-directional RTP audio and video 14 media. 15 16 Step 2 17 18 The user of PSVT Terminal 1 decides to remove the video stream. 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 Figure 12 Call Flow for User-Initiated Removal of Video Stream from PSVT Call 59 60
22 3GPP2 C.S0055-A v1.0
1 Step 3 2 3 PSVT Terminal 1 constructs a SIP re-INVITE request and sends this to the P-CSCF of PSVT Terminal 1. The 4 SDP parameters to be included in the SIP re-INVITE are as specified in 5.5.1 and sets the port number for the 5 video media (m=) line to zero. PSVT Terminal 1 continues to use the same audio media (m=) line from the 6 7 previously negotiated SDP to prevent interruption in the voice media decoding. PSVT Terminal 1 continues to 8 send voice media and stop sending video media. 9 10 Step 4 11 12 The P-CSCF sends a 100 Trying response to the re-INVITE. The IMS CN performs processing of the re- 13 INVITE request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. 14 15 Step 5 16 17 Upon receiving the re-INVITE request PSVT Terminal 2 notifies its user that the video media is to be removed. 18 19 Step 6 20 21 PSVT Terminal 2 responds with a 200 OK that contains the SDP Answer parameters specified in 5.5.2 and sets 22 the port number for the video media (m=) line to zero. 23 24 25 Step 7 26 27 PSVT Terminal 2 deactivates its QoS for the (bi-directional) video flow and stop sending video media 28 immediately. PSVT Terminal 2 continues to send voice media. 29 30 Step 8 31 32 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. 33 34 Step 9 35 36 PSVT Terminal 1 deactivates its QoS for the (bi-directional) video flow. 37 38 Step 10 39 40 41 PSVT Terminal 1 sends an ACK request to acknowledge the 200 OK. 42 43 Step 11 44 45 The IMS CN forwards the ACK to PSVT Terminal 2. 46 47 Step 12 48 49 Terminals 1 and 2 continue to exchange bidirectional RTP voice using the negotiated codecs. 50 51 5.4.2.2 Network-Initiated Removal of Video from a PSVT Call 52 53 54 The following section describes how bi-directional video media is removed from an existing PSVT call (Figure 55 13). 56 57 Step 1 58 59 60
23
3GPP2 C.S0055-A v1.0
1 2 The two terminals are involved in a PSVT call and are actively exchanging bi-directional RTP voice and video 3 media. 4 5 Step 2 6 7 PSVT Terminal 1 is notified that the Radio Access Network deactivated the QoS for the video flow and PSVT 8 9 Terminal 1 has been configured to continue operation in VoIP-only mode. PSVT Terminal 1 immediately stops 10 sending video media to PSVT Terminal 2. PSVT Terminal 1 also stops decoding video media that it may 11 receive on other (non-video) flows from the RAN. 12 13 14 PSVT Terminal PSVT Terminal 15 IMS CN 16 1 2 17 18 19 1. RTP voice and video over corresponding flows 20 21 22 23 24 2. QoS for video flow 25 deactivated by RAN 5. Indicate that video 26 stream is to be removed 27 28 29 30 3. re-INVITE (SDP offer) 31 100 Trying 4. re-INVITE (SDP offer) 32 100 Trying 33 34 35 6. 200 OK (SDP answer) 36 8. 200 OK (SDP answer) 37 38 7. De-activate 39 QoS for video flow 40 9. ACK 41 10. ACK 42 43 11. RTP voice over voice flow 44 45 46 47 48 49 50 51 52 53 54 Figure 13 Call Flow for Network-Initiated Removal of Video Stream from PSVT Call 55 56 Step 3 57 58 PSVT Terminal 1 constructs a SIP re-INVITE request and sends this to the P-CSCF of PSVT Terminal 1. The 59 60 SDP parameters to be included in the SIP re-INVITE are as specified in 5.5.1 and sets the port number for the
24 3GPP2 C.S0055-A v1.0
1 video media (m=) line to zero. PSVT Terminal 1 continues to use the same audio media (m=) line from the 2 previously negotiated SDP to prevent interruption in the voice media decoding. 3 4 Step 4 5 6 7 The P-CSCF sends a 100 Trying response to the re-INVITE. The IMS CN performs processing of the re- 8 INVITE request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. 9 10 Step 5 11 12 Upon receiving the re-INVITE request PSVT Terminal 2 notifies its user that the video media is to be removed. 13 14 Step 6 15 16 PSVT Terminal 2 responds with a 200 OK that contains the SDP Answer parameters specified in 5.5.2 and sets 17 the port number for the video media (m=) line to zero. 18 19 Step 7 20 21 PSVT Terminal 2 deactivates its QoS for the (bi-directional) video flow and stop sending video media 22 23 immediately. PSVT Terminal 2 continues to send voice media. 24 25 Step 8 26 27 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. 28 29 Step 9 30 31 PSVT Terminal 1 sends an ACK request to acknowledge the 200 OK. 32 33 Step 10 34 35 The IMS CN forwards the ACK to PSVT Terminal 2. 36 37 Step 11 38 39 40 Terminals 1 and 2 continue to exchange bidirectional RTP voice using the negotiated codecs. 41 42 5.5 Session Description Protocol (SDP) Parameters (Informative) 43 44 45 5.5.1 SDP Offer 46 47 The SDP parameters included in the SIP INVITE are as follows. 48 49 • The following procedures are recommended in this document: 50 51 52 o The SDP offer typically contains at least one audio media line (m=) offering one or more RTP 53 payload formats. For each media line, the codecs are listed in order of decreasing preference with 54 the most preferred codec listed first. 55 o The SDP offer contains one bandwidth line (b=) for the voice media at the media-level with AS 56 modifier [32] set to the application-specific bandwidth for the voice session. This bandwidth 57 value includes the overhead of the uncompressed RTP/UDP/IP headers. 58 59 60
25
3GPP2 C.S0055-A v1.0
1 2 o The SDP offer may contain one bandwidth line (b=) for the voice media at the media-level with 3 TIAS modifier [29] set to the transport independent application-specific bandwidth for the voice 4 session. 5 6 o The SDP offer contains at least one video media line (m=) offering one or more RTP payload 7 formats. For each media line, the codecs are listed in order of decreasing preference with the most 8 preferred codec listed first. 9 10 o The SDP offer contains one bandwidth line (b=) for the video media at the media-level with AS 11 modifier set to the application-specific bandwidth for the video session. This bandwidth value 12 includes the overhead of the uncompressed RTP/UDP/IP headers. 13 o The SDP offer may contain one bandwidth line (b=) for the video media at the media-level with 14 TIAS modifier [29] set to the transport independent application-specific bandwidth for the video 15 session. 16 17 o The SDP offer contains the media level attributes for indicating preconditions and the 18 “precondition” option tag is included in the SIP header. 19 20 • Other SDP lines for negotiating features may be present. 21 22 5.5.2 SDP Answer 23 24 The following information is included in this SDP answer: 25 26 27 • The following procedures are recommended in this document: 28 29 o The SDP answer for each audio media line (m=) typically contains only one codec format, i.e., the 30 first codec format in the offer that can be used by the answering PSVT Terminal for the PSVT 31 session. 32 o The SDP answer contains one bandwidth line (b=) for the voice media at the media-level with AS 33 modifier set to the application-specific bandwidth for the voice session. 34 35 o The SDP answer may contain one bandwidth line (b=) for the voice media at the media-level with 36 TIAS modifier [29] set to the transport independent application-specific bandwidth for the voice 37 session. 38 39 o The SDP answer for each video media line (m=) typically contains only one codec format, i.e., the 40 first codec format in the offer that can be used by the answering PSVT Terminal for the PSVT 41 session. 42 o The SDP answer contains one bandwidth line (b=) for the video media at the media-level with AS 43 modifier set to the application-specific bandwidth for the video session. 44 45 o The SDP answer may contain one bandwidth line (b=) for the video media at the media-level with 46 TIAS modifier [29] set to the transport independent application-specific bandwidth for the video 47 session. 48 49 o The SDP answer contains the media level attributes for indicating preconditions and the 50 “precondition” option tag is included in the SIP header. 51 • Other SDP lines for negotiating features may be present. 52 53 54 55 56 57 58 59 60
26 3GPP2 C.S0055-A v1.0
1 2 3 6 Media 4 5 This section describes the media codecs to be used with the PSVT service, their RTP payload formats for 6 transport over UDP/IP, and recommendations for processing the media transport. 7 8 9 6.1 Codecs 10 11 The PSVT service uses two media types: video and voice. The codec formats to be used to encode and decode 12 these media types are specified in this section. 13 14 6.1.1 Video 15 16 17 Within the constraints of this specification, video may be encoded using a large variety of video encoding 18 schemes — many of which have multiple options. The resulting number of possible combinations is large. 19 Therefore, a single mandatory video codec and a limited number of optional codecs is preferable in order to 20 achieve a high degree of compatibility while allowing high quality transmissions encoded with advanced 21 techniques. 22 23 The PSVT Terminal shall support H.263 Profile 0 Level 10. The SDP offer shall contain H.263 Profile 0 Level 24 10 as a video codec. 25 26 27 The PSVT Terminal should support H.263 Profile 0 Level 45. 28 29 The PSVT Terminal should support MPEG-4 Visual Simple Profile Level 0b. 30 31 The PSVT Terminal should support H.264/AVC Baseline profile at level 1b, with constraint_set1_flag=1. 32 33 If the PSVT Terminal also supports and has available resources to use H.264/AVC and/or MPEG-4 then the 34 video m-line in the SDP offer shall contain H.264/AVC and/or MPEG-4 as a higher preference than H.263. 35 36 6.1.2 Voice 37 38 39 The PSVT Terminal shall support the EVRC-B codec as specified in [11]. EVRC-B is the default voice codec 40 for PSVT Terminals. The audio m-lines of the SDP offer shall include EVRC-B as one of the offered codecs. 41 42 Wideband-capable PSVT terminals shall support EVRC-WB [11] and EVRC-B [11] codecs. EVRC-WB is the 43 default codec and most preferred codec for wideband-capable PSVT terminals. The audio m-lines of the SDP 44 offer shall contain EVRC-WB as the first of the offered codecs. 45 46 The selection of the voice codec used in a specific PSVT call (including codecs not in this specification) shall 47 follow [24] for non-IMS call control scenarios and [19] for IMS call control scenarios. 48 49 50 6.2 Transport 51 52 This section specifies the transport layer requirement for the PSVT Terminal. 53 54 • The RTP payload format defined in [35] shall be supported for the transport of EVRC-B media. The 55 Header-Free packet format should be used. 56 57 58 • The RTP payload format defined in [37] shall be supported for the transport of EVRC-WB media. The 59 Header-Free packet format should be used. 60
27
3GPP2 C.S0055-A v1.0
1 2 • The RTP payload format defined in [34] shall be supported for the transport of H.263 media. 3 4 • The RTP payload format defined in [21] shall be supported for the transport of MPEG-4 media (if 5 used). 6 7 8 • The RTP payload format defined in [30] shall be supported for the transport of H.264/AVC media (if 9 used). 10 11 Terminals should send RTCP Sender Reports when both voice and video streams are active to provide 12 synchronization of these streams. Terminals that receive these RTCP Sender Reports should use this 13 information when synchronizing the playout of these streams. 14 15 6.2.1 Header Compression 16 17 18 To reduce RTP/UDP/IP overhead of the media streams, PSVT terminals should use Robust Header 19 Compression (ROHC) [22]. 20 21 If ROHC is used it shall be operated in the Optimistic ‘O’ mode. 22 23 ROHC is applied independently to the video and voice media streams. If ROHC is used to compress the voice 24 media stream, ROHC timer based compression of the RTP timestamp shall be used for the RTP voice traffic. If 25 ROHC is used to compress the video media stream, ROHC timer based compression shall not be used for the 26 RTP video traffic. 27 28 29 6.2.2 Media Synchronization 30 31 The Synchronization Info attribute defined in this section allows a 3GPP2 PSVT terminal to specify whether 32 media streams should be synchronized with each other. This applies to all types of media, including voice, 33 video, text, etc… 34 35 If synchronization is required, the application determines the amount of skew that is acceptable based on the use 36 case/service. Once a terminal has determined the synchronization requirement for the service it should 37 negotiate the appropriate QoS treatment with the Radio Access Network. For streams not requiring 38 synchronization with a conversational/interactive flow, the terminal should negotiate a more relaxed QoS 39 treatment such as for “streaming” or “best-effort” delivery. 40 41 42 The ABNF for the synchronization info attribute shall be as described in section 6.2.6 of [38]. The syntax and 43 the usage of the synchronization attribute shall be as described in section 6.2.6 of [38]. 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
28 3GPP2 C.S0055-A v1.0
1 2 3 7 Quality of Service (QoS) 4 5 To provide a reliable and good quality PSVT service requires that the radio access network provide the 6 appropriate Quality of Service (QoS) for transporting the media and control traffic. 7 8 9 7.1 Radio Link QoS Configuration and Activation 10 11 To enable this the PSVT Terminal requests activation of QoS from the radio access network. This section 12 specifies procedures that the PSVT Terminal uses to determine the appropriate QoS levels to request from the 13 network. 14 15 16 7.1.1 Configuring QoS Reservations 17 18 As described in section 5.1, when the PSVT feature is initialized the PSVT Terminal configures a set of default 19 QoS reservations with the RAN for the SIP, voice, and video traffic. RTCP traffic for the voice and video flows 20 may be transported over the same QoS flow as the SIP traffic or over separate QoS flows. Each QoS 21 reservation is referenced by the PSVT Terminal and RAN using an 8-bit FLOW_ID value as specified in [17]. 22 23 For each QoS flow, the PSVT Terminal can request one or more QoS_ATTRIBUTE_SETs as specified in [17]. 24 A QoS_ATTRIBUTE_SET can describe the QoS requirement using a FlowProfileID or more verbose QoS 25 parameters. For PSVT, the terminals should include the FlowProfileID in the QoS_ATTRIBUTE_SET and not 26 the verbose QoS parameters. 27 28 29 If multiple QoS_ATTRIBUTE_SETs are requested for a particular flow the sets are listed in order of decreasing 30 preference. The RAN follows this preferential ordering when determining which QoS_ATTRIBUTE_SET to 31 grant to the PSVT Terminal. 32 33 For the SIP traffic and RTCP traffic, the PSVT Terminal should configure a QoS reservation to include a 34 FlowProfileID defined for conversational media control signalling as specified in [40]. The PSVT Terminal 35 shall bind this QoS reservation with the link flow that will transport the SIP and/or RTCP traffic. As described 36 in section 6.2, the reservation for carrying SIP traffic is activated immediately upon PSVT feature initialization 37 to allow the PSVT Terminal to send and receive SIP messages without activation delay. 38 39 Configuration of the QoS_ATTRIBUTE_SETs for the video and voice QoS flows is described in the rest of this 40 section. 41 42 7.1.1.1 Single QoS_ATTRIBUTE_SET for a media type 43 44 45 If all the codecs supported1 by the PSVT Terminal for a media type can use one setting of a 46 QoS_ATTRIBUTE_SET to support the QoS requirements of the codec(s) then the PSVT Terminal should 47 configure this QoS_ATTRIBUTE_SET with the RAN and bind it to the link flow that will transport the traffic 48 for the media type. 49 50 51 52 53 54 55 56 57
58 59 1 This refers to codecs that are supported by the terminal and are allowed for the PSVT session. 60
29
3GPP2 C.S0055-A v1.0
1 2 7.1.1.2 Multiple QoS_ATTRIBUTE_SETs for a media type 3 4 5 If all the codecs supported1 by the PSVT Terminal for a media type require more than one 6 QoS_ATTRIBUTE_SET then the PSVT Terminal should configure multiple QoS reservations with the RAN 7 according to the procedures specified in this section. These procedures should be performed for each media 8 type whose supported codecs require multiple settings of the QoS_ATTRIBUTE_SETs. 9 10 For the purpose of specifying the PSVT Terminal operation the following conventions are defined here: 11 12 • Let M be the number of distinct QoS_ATTRIBUTE_SETs that the PSVT Terminal requires for the 13 codecs it supports for a particular media type. 14 15 16 • Label the M distinct QoS_ATTRIBUTE_SETs as {QoS_ATTRIBUTE_SET_1, 17 QoS_ATTRIBUTE_SET_2,…QoS_ATTRIBUTE_SET_M} in order of increasing QoS resource 18 requirements on the RAN . 19 20 • Label each QoS reservation with a “Reservation Number” as a reference 21 22 The PSVT Terminal should configure M distinct QoS reservations according to Table 1. If the PSVT Terminal 23 or network is unable to configure all of the listed QoS reservations then the PSVT Terminal shall perform the 24 following: 25 26 • The PSVT Terminal shall configure the reservation which includes the highest 27 QoS_ATTRIBUTE_SET, i.e., Reservation Number M in Table 1 which requires the most QoS 28 resources from the network. 29 30 31 • The PSVT Terminal shall configure the reservation which includes the QoS_ATTRIBUTE_SET for 32 the most preferred RTP payload type as the first attribute set in the reservation, i.e., the most preferred 33 QoS_ATTRIBUTE_SET is for the most preferred codec. 34 35 • The PSVT Terminal should configure as many of the reservations with the next highest 36 QoS_ATTRIBUTE_SETs as possible, i.e., Reservation Numbers M-1, M-2, M-3,... in Table 1. 37 38 Table 1 QoS Reservations for Multiple QoS_ATTRIBUTE_SETs 39 40 Reservation Included QoS_ATTRIBUTE_SETs 41 42 Number 43 (in order of decreasing preference) 44 45 1 QoS_ATTRIBUTE_SET_1 46 47 2 QoS_ATTRIBUTE_SET_2, QoS_ATTRIBUTE_SET_1 48 49 … … 50 51 K QoS_ATTRIBUTE_SET_k, QoS_ATTRIBUTE_SET_(k-1), …, QoS_ATTRIBUTE_SET_1 52 53 … 54 … 55 56 57
58 59 1 60 This refers to codecs that are supported by the terminal and are allowed for the PSVT session.
30 3GPP2 C.S0055-A v1.0
1 2 M-1 QoS_ATTRIBUTE_SET_(M-1), QoS_ATTRIBUTE_SET_(M-2), …, QoS_ATTRIBUTE_SET_1 3 4 M QoS_ATTRIBUTE_SET_M, QoS_ATTRIBUTE_SET_(M-1), …, QoS_ATTRIBUTE_SET_1 5 6 7 8 The PSVT Terminal shall bind each of the QoS reservations with the link flow that will transport the traffic for 9 the media type. 10 11 12 Section 12 provides an example QoS BLoB for configuring one QoS reservation when the video media can 13 operate its codecs at 48kbps or 32kbps. The FlowProfileID for 48kbps video is listed as a higher preference 14 than that for 32kbps. If the PSVT Terminal were to configure a second QoS reservation following the 15 procedures in this section, the PSVT Terminal would only include the FlowProfileID for 32kbps video for the 16 video QoS flow in the second QoS configuration. 17 18 7.1.2 Activating QoS at Call Origination 19 20 21 When the user originates a PSVT call, the calling PSVT Terminal shall request activation of the pre-configured 22 QoS reservation for each media type according to the procedures in this section. 23 24 7.1.2.1 Single QoS_ATTRIBUTE_SET for a media type 25 26 The PSVT Terminal shall request activation of the QoS reservation with the single QoS_ATTRIBUTE_SET. 27 28 If this request is granted then the PSVT Terminal shall continue the call set-up by including in the SDP offer the 29 RTP payload type(s) for codec(s) whose QoS requirements match those granted by the RAN. 30 31 32 If the request is not granted then the PSVT Terminal shall only continue the call set-up if the service and user 33 allow the call to continue without this media type. If the call set-up continues the PSVT Terminal shall not 34 include the media line for this media type in the SDP offer. 35 36 7.1.2.2 Multiple QoS_ATTRIBUTE_SETs for a media type 37 38 The PSVT Terminal should request activation of the QoS reservation that includes the QoS_ATTRIBUTE_SET 39 values for the most preferred RTP payload type as the first attribute set in the reservation, i.e., the most 40 preferred QoS_ATTRIBUTE_SET is for the most preferred codec in the SDP offer. 41 42 43 If the RAN grants the most preferred QoS_ATTRIBUTE_SET then the PSVT Terminal should continue the call 44 set-up by including in the SDP offer all the RTP payload type(s) for the media type. 45 46 If the RAN does not grant the most preferred QoS_ATTRIBUTE_SET but grants one of the other requested 47 QoS_ATTRIBUTE_SETs then the PSVT Terminal shall continue the call set-up by including in the SDP offer 48 the RTP payload type(s) for codec(s) whose QoS requirements match or are below the QoS resources granted 49 by the RAN. 50 51 The PSVT Terminal includes RTP payload types in the media line of the SDP offer in order of decreasing 52 preference. The PSVT Terminal shall not include any RTP payload types that require more QoS resources than 53 granted by the RAN. 54 55 If none of the requested QoS_ATTRIBUTE_SETs are granted by the RAN then the PSVT Terminal shall only 56 continue the call set-up if the service and user allow the call to continue without this media type. If the call set- 57 up continues the PSVT Terminal shall not include the media line for this media type in the SDP offer. 58 59 60
31
3GPP2 C.S0055-A v1.0
1 2 7.1.3 Activating QoS at Call Answering 3 4 5 When the answering PSVT Terminal receives the SDP offer it determines a candidate codec by selecting the 6 first codec that it supports in the list of the RTP payload types for a particular media line. 7 8 After selecting the candidate codec, the PSVT Terminal shall request activation of the QoS reservation whose 9 first (most preferred) QoS_ATTRIBUTE_SET matches the QoS requirements of the candidate codec. The 10 PSVT Terminal should use information in the SDP offer to estimate the QoS requirements of the candidate 11 codec. 12 13 If there is no existing QoS reservation whose first QoS_ATTRIBUTE_SET matches the QoS requirements of 14 the candidate codec, the PSVT Terminal shall request activation of a QoS reservation whose first 15 QoS_ATTRIBUTE_SET exceeds the QoS requirements of the candidate codec. To minimize activation of 16 unnecessary QoS resources and maximize the probability of being granted the request, the PSVT Terminal 17 should request activation of the existing QoS reservation whose first QoS_ATTRIBUTE_SET exceeds the QoS 18 19 requirements of the candidate codec by the least amount. 20 21 If the RAN grants one of the requested QoS_ATTRIBUTE_SETs then the PSVT Terminal shall continue the 22 call set-up. The PSVT Terminal shall include in the SDP answer the first RTP payload type listed in the SDP 23 offer that meets the following criteria: 24 25 • The codec is supported by the answering PSVT Terminal. 26 27 • The QoS requirements for the codec match or are below the QoS resources granted by the RAN. The 28 PSVT Terminal shall not include an RTP payload type that requires more QoS resources than granted 29 by the RAN. 30 31 If none of the requested QoS_ATTRIBUTE_SETs are granted by the RAN then the PSVT Terminal shall only 32 continue the call set-up if the service and user allow the call to continue without this media type. If the call set- 33 up continues the PSVT Terminal shall set the port number for the corresponding media line to zero in the SDP 34 35 answer. 36 37 7.1.4 QoS Adjustments at the Calling and Answering Terminals 38 39 Once the calling and answering terminals have selected the codec to use for the media type, the terminals 40 should check if the QoS requirements for the codec will fully utilize the QoS resources granted by the RAN to 41 the PSVT Terminal. 42 43 44 If the selected codec will persistently under-utilize the granted QoS resources (which may be triggered by 45 various events during a call) the PSVT Terminal should request activation of a more appropriate 46 QoS_ATTRIBUTE_SET from the RAN to match the codec requirements. This re-negotiation of QoS with the 47 RAN conserves network resources. To minimize call set-up time the exchange of SIP messages during call set- 48 up should not wait for this re-negotiation of RAN QoS to be performed. 49 50 51 52 53 54 55 56 57 58 59 60
32 3GPP2 C.S0055-A v1.0
1 2 3 8 Error Resiliency 4 5 A 3GPP2 PSVT Terminal might not receive media packets in time to be used for decoding for the following 6 reasons: 7 8 • The packet is corrupted (e.g., corrupted over the wireless link or other links in the network) 9 10 11 • The packet is dropped at intermediate nodes in the media path from the sender to the receiver due to 12 congestion and delay 13 14 • The packet does not arrive in time for decoding at the receiver 15 16 To minimize the perceived effects caused by such packet losses and general errors in decoding reference video 17 frames the following procedures are defined for PSVT terminals. 18 19 8.1 Packet and Picture Loss Indication 20 21 22 For predictive coding algorithms such as the inter-frame encoding used by the codecs specified in section 6, a 23 packet loss or any decoding errors in reference video frames cause the propagation of errors in successive 24 frames that reference the lost packet or incorrectly decoded reference frame. 25 26 The procedures defined in this section allow the receiver to indicate to the sender that particular packets have 27 been lost or that a reference frame has been incorrectly decoded. The sender can use this indication to mitigate 28 the propagation of errors caused by the lost packets or incorrectly decoded reference frame. 29 30 3GPP2 PSVT terminals shall use the ‘Generic NACK’ and the ‘Picture Loss Indication (PLI)’ message 31 specified in sections 6.2.1 and 6.3.1 of [33], respectively, to provide packet and picture loss feedback 32 33 information for the video streams. The following subsections specify the details of how this shall be done. 34 35 8.1.1 SDP Definitions 36 37 As specified in section 4 of [33] a sender that supports the Generic NACK and Picture Loss Indication (PLI) 38 messages must support the RTP/AVPF profile. The sender shall identify this profile as specified in sections 4.1 39 of [33]. 3GPP2 PSVT terminals shall support the ability to offer, parse, and negotiate use of the RTP/AVP and 40 RTP/AVPF profiles. SDP Capability negotiation [39] should be used to efficiently negotiate the usage of AVPF 41 42 or AVP profiles. When SDP Capability Negotiation is supported, the RTP/AVPF profile shall be included in the 43 'm'-line as the default profile. The associated 'a'-line listing the potential configurations shall indicate that 44 RTP/AVPF is preferred over the RTP/AVP profile. When SDP Capability Negotiation is not supported by the 45 offering PSVT terminal, its first offer shall indicate support for the use of the RTP/AVPF profile for the PSVT 46 session. If the answering terminal does not support RTP/AVPF, the offering terminal shall re-attempt to 47 negotiate the use of the RTP/AVP profile by including it in the subsequent SDP offer. 48 49 The 3GPP2 PSVT terminal shall indicate the capability to accept Generic NACK and Picture Loss Indication 50 (PLI) messages for a particular codec using the procedures specified in section 4.2 of [33]. 51 52 Following is an example SDP media line offer where the sender’s H.263 video source accepts generic NACK 53 and Picture Loss Indication messages: 54 55 m=video 51372 RTP/AVPF 98 56 57 c=IN IP4 192.46.126.56 58 59 60
33
3GPP2 C.S0055-A v1.0
1 2 a=rtpmap:98 H263/90000 3 4 a=rtcp-fb:98 nack 5 6 a=rtcp-fb:98 nack pli 7 8 9 10 When a 3GPP2 PSVT terminal receives the above indication in SDP the PSVT Terminal shall use the Generic 11 NACK procedures defined in section 8.1.2. and PLI procedures defined in section 8.1.3. 12 13 8.1.2 Operation 14 15
16 17 18 8.1.2.1 GNACK 19 20 21 When a 3GPP2 PSVT Terminal receiver determines that one or more packets are lost, the PSVT Terminal shall 22 send a Generic NACK message to the RTP sender indicating which packets are lost. If the receiver is to report 23 multiple packet losses, the receiver should compile these reports into one Generic NACK message to minimize 24 the number of NACK messages that are sent. 25 26 When the sender receives the Generic NACK the sender should attempt to mitigate the propagation of errors at 27 the receiver caused by the lost packet(s). 28 29 8.1.2.2 PLI 30 31 32 A video receiver could encounter decoding error conditions where the receiver can not identify RTP packets 33 that would have transported the missing or corrupted data. When a 3GPP2 PSVT Terminal receiver detects 34 such an error condition that can not be corrected by a Generic NACK request the PSVT Terminal shall send a 35 Picture Loss Indication (PLI) message to the RTP sender. 36 37 When the video sender receives the Picture Loss Indication the sender should attempt to mitigate the 38 propagation of errors at the receiver caused by the loss or corruption of the reference frame. 39 40 8.1.3 Feedback Rate 41 42 43 In [26] and [27] standard restrictions are placed on the amount of bandwidth that can be used to send RTCP 44 messages. If the PSVT Terminal determines that more RTCP bandwidth is required to send Generic NACK or 45 Picture Loss Indication messages at a faster rate, the PSVT Terminal may use the RTCP bandwidth modifiers 46 specified in [28] to override the default RTCP bandwidth restrictions. 47 48 49 50 51 52 53 54 55 56 57 58 59 60
34 3GPP2 C.S0055-A v1.0
1 2 3 9 Adaptation 4 5 PSVT terminals that support dynamic end-to-end video rate adaptation can show significant improvements to 6 the performance of the PSVT session over the HRPD radio access interface. Dynamic rate adaptation allows the 7 PSVT terminal to vary its encoding rate to track variations in the end to end channel conditions within the 8 granted QoS level. 9 10 As the network becomes more loaded or the PSVT terminal moves into poorer link conditions the terminal 11 detects changes in the statistics of packets arriving at the receiver terminal. Based on these measurements the 12 terminal sends a feedback message to the video sender indicating a need to throttle back its encoding/sending 13 14 rate. The encoder at the video sender modifies its rate based on this feedback message. 15 16 When the link or loading conditions improve, the PSVT terminal signals this back to the video encoder. The 17 video encoder can use this information to conservatively increase its encoding/transmission rate. 18 19 The information to be fed back from the video receiver PSVT terminal to the video sender PSVT terminal is 20 described in section 9.1 21 22 The PSVT terminal shall support transmission of the APTO_ARR RTCP feedback message for end-to-end 23 dynamic video rate adaptation as described in section 9.1. The PSVT terminal shall support dynamic video rate 24 adaptation upon receiving the APTO_ARR RTCP APP packet feedback message. 25 26 The SDP parameters to negotiate the capability to support the APTO-ARR RTCP APP packet feedback 27 message and the terminal capability to adapt its transmission rate based on this feedback message are described 28 in section 9.2. 29 30 31 32 33 9.1 Rate Adaptation Feedback Message 34 35 The format of the APTO_ARR RTCP APP packet is described in Figure 14 below. 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 Figure 14 Format for APTO_ARR RTCP APP Packet 52 53 For video adaptation the name and subtype fields must be set to the following values: 54 55 subtype: This field shall be set to 0 for the APTO_ARR format. 56 57 58 length: The number of 32 bit words –1, as defined in [26]. This means that the field will be 2+3*N, where N is 59 the number of sources reported on. The length field will typically be 5, i.e. 24 bytes packets. 60
35
3GPP2 C.S0055-A v1.0
1 2 SSRC: The SSRC of the media stream the received packets belong to. 3 4 name: The APTO_ARR APP data format is detected through the name "PSVT" and the subtype set to “0”. 5 6 Arrival-to-Playout Offset (16 bits): The difference between the arrival time of RTP media packets and their 7 properly scheduled playout time. The offset is expressed as a signed 16-bit integer in units of milliseconds. 8 9 When the value is negative it indicates that RTP packets are arriving earlier than their properly scheduled 10 playout time and a positive value indicates that the packets are arriving later than their playout time. 11 12 If Ai is the arrival time of packet i and Pi is the scheduled playout time of packet i then the offset value for the 13 packet, Di, is calculated as follows: 14 15 Di = Ai – Pi 16 17 The Di values MUST be calculated for all packets received. If multiple RTP packets have the same RTP 18 timestamp/playout time (e.g., multiple slices of a video frame have the same playout time) then Di should be 19 calculated only for the last arrived packet with this RTP timestamp. 20 21 Since the individual Di values are affected by jitter a filtered statistic of the Di values shall be reported in the 22 Arrival-to-Playout Offset field of this message. 23 24 Average Received Rate (16 bits): This is the average rate of RTP media received by the receiver. The Average 25 Received Rate value is expressed in units of 256bps. The window over which the Average Received Rate is 26 27 measured should be the same as the window over which the Arrival-to-Playout Offset statistic is measured. 28 29 9.1.1 General Semantics for Using APTO_ARR Message 30 31 A video receiver should only send the APTO_ARR APP packet when the receiver determines that video 32 adaptation is required at the sender. When a video receiver sends an APTO_ARR APP packet it should allow 33 the video sender enough time to react before the receiver sends another APTO_ARR APP packet. To enable 34 transmission of this RTCP APP packet when needed the terminals should use the RTCP-AVPF early mode [33]. 35 36 37 [26] and [27] place standard restrictions on the amount of bandwidth that can be used to send RTCP messages. 38 If the PSVT Terminal determines that more RTCP bandwidth is required to send the feedback messages at a 39 faster rate, the PSVT Terminal may use the RTCP bandwidth modifiers specified in [28] to override the default 40 RTCP bandwidth restrictions. 41 42 43 44 9.2 SDP Definitions 45 46 47 PSVT terminal receivers sending APTO_ARR RTCP feedback messages and PSVT terminal senders capable of 48 adapting their transmission in response to such signaling shall signal the support of such capabilities using the 49 APTO_ARR application layer feedback SDP parameter. The PSVT terminal shall support the RTP/AVPF 50 profile [33] and its negotiation as specified in 8.1.1. 51 52 Following the framework of Section 4.2 of [33] that specifies the syntax for the RTCP feedback messages, the 53 application layer feedback parameter for signaling support of APTO_ARR RTCP APP packet is defined as: 54 55 56 57 rtcp-fb-param = SP "app" ”apto-arr” SP
36 3GPP2 C.S0055-A v1.0
1 where the
37
3GPP2 C.S0055-A v1.0
1 2 • The answerer is not capable of feeding back APTO_ARR APP packets to the offerer or adapting its 3 4 transmission to APTO_ARR APP packets received from the offerer. 5 6 When the “a=rtcp-fb” line with the “apto-arr” parameter is included in the SDP answer the direction parameter 7 indicates the following: 8 9 9.2.2.1 Sendrecv 10 11 12 The “sendrecv” direction indicates that, 13 14 • The answerer can generate and feedback APTO_ARR APP packets for the stream in the direction 15 offerer -> answerer, and 16 17 18 • The answerer can adapt its transmission for the stream in direction answerer -> offerer based on the 19 APTO_ARR APP packet feedback it receives from the offerer. 20 21 The “sendrecv” direction can only be set in the SDP answer for a media stream if the offerer has indicated in its 22 SDP offer that it can both feedback APTO_ARR APP packets to the answerer and adapt its transmission to 23 APTO_ARR APP packet feedback it receives from the answerer. 24 25 Following is an example of a possible answer to example offer in section 3.1.1: 26 27 m=video 43246 RTP/AVPF 98 28 a=rtpmap:98 H263-2000/90000 29 30 a=rtcp-fb:98 app apto-arr sendrecv 31 32 9.2.2.2 Sendonly 33 34 35 The “sendonly” direction of the attribute indicates that, 36 37 • The answerer can generate and feedback APTO_ARR APP packets for the stream in the direction 38 offerer -> answerer, and 39 40 41 • The answerer can not adapt its transmission for the stream in the direction answerer -> offerer based on 42 the APTO_ARR APP packet feedback it receives from the offerer. 43 44 The “sendonly” direction can only be set in the SDP answer for a media stream if the offerer has indicated in its 45 SDP offer that it can adapt its transmission to APTO_ARR APP packet feedback it receives from the answerer. 46 47 Following is an example of a possible answer to example offers in section 3.1.1 and 3.1.3: 48 49 m=video 43246 RTP/AVPF 98 50 51 a=rtpmap:98 H263-2000/90000 52 a=rtcp-fb:98 app apto-arr sendonly 53 54 9.2.2.3 Recvonly 55 56 57 The “recvonly” direction of the attribute indicates that, 58 59 60
38 3GPP2 C.S0055-A v1.0
1 2 • The answerer can adapt its transmission for the stream in the direction answerer-> offerer based on the 3 APTO_ARR APP packet feedback it receives from the offerer, and 4 5 • The answerer can not generate and feedback APTO_ARR APP packets for the stream in the direction 6 offerer -> answerer. 7 8 9 The “recvonly” direction can only be set in the SDP answer for a media stream if the offerer has indicated in its 10 SDP offer that it can feedback APTO_ARR APP packets to the answerer. 11 12 Following is an example of a possible answer to example offers in section 3.1.1 and 3.1.2: 13 m=video 43246 RTP/AVPF 98 14 15 a=rtpmap:98 H264/90000 16 a=rtcp-fb:98 app apto-arr recvonly 17 18
19 Table 2 summarizes the allowable the direction parameter values in an SDP answer in response to a 20 corresponding SDP offer: 21 22 23 24 25 Table 2 Allowable setting of “apto-arr”
39
3GPP2 C.S0055-A v1.0
1 2 9.2.3 Multiple Payload Types 3 4 5 When multiple payload types are offered an “rtcp-fb” line with the “apto-arr” parameter shall follow each 6 payload type which supports feedback of APTO_ARR APP packets and/or adapting transmission. Following is 7 an example SDP offer illustrating this: 8
9 m=video 51372 RTP/AVPF 98 99 10 11 a=rtpmap:98 H263-2000/90000 12 13 a=rtcp-fb:98 app apto-arr sendrecv 14 a=rtpmap:99 H264/90000 15 16 a=rtcp-fb:99 app apto-arr sendonly 17 18 19 20 The above example offer indicates that the offer is able to send APTO_ARR APP packet feedback regardless of 21 which video codec is selected. This can be expected since the feedback generation should be generally 22 independent of the decoder. However the terminal is only able to support video transmission adaptation for the 23 H.263 encoder. It does not support transmission adaptation on the H.264 encoder as could be initially expected 24 for the more recently standardized and complex H.264 codec. 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
40 3GPP2 C.S0055-A v1.0
1 2 3 10 Security and Encryption 4 5 If security and SIP encryption are required for PSVT over IMS they shall be provided using the procedures 6 specified in [41]. 7 8 End-to-end encryption of media is required to provide secure communication between PSVT terminals. 9 Procedures for end-to-end media encryption between PSVT terminals are not specified at this time. 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
41
3GPP2 C.S0055-A v1.0
1 2 3 4 11 PSVT Session Handling for HRPD to 5 cdma2000 1xCS Domain Transfer 6 7 8 Session continuity allows the user to move the voice media component of their ongoing video telephony session 9 from the packet switched domain to the circuit switched domain, e.g., transfer from HRPD to cdma2000 1x CS 10 networks that do not support video telephony applications. The voice media component of a PSVT session can 11 12 be handed off to the 1xCS network through a domain transfer (DT) as specified in [36]. A PSVT terminal 13 capable of supporting domain transfer from HRPD to 1xCS voice is also referred to as a VCC UE. 14 15 16 11.1 PSVT terminal roles for registration in HRPD 17 18 A PSVT terminal with VCC capability shall follow the registration procedures described in section 5.3.2 of 19 [36]. 20 21 22 11.2 PSVT terminal roles for Call Origination 23 24 A PSVT terminal with VCC capability shall follow the call origination procedures described in section 5.4.2 of 25 [36]. 26 27 28 11.3 PSVT terminal roles during Call Termination 29 30 A PSVT terminal that terminates calls subject to VCC shall follow procedures described in section 5.5.2 of [36]. 31 32 33 34 11.4 PSVT terminal roles during Domain Transfer (DT) 35 36 A PSVT terminal with VCC capability shall follow the call procedures described in this section. 37 38 39 11.4.1 Releasing Video media of the ongoing PSVT session during DT 40 41 42 When the HRPD AN determines that the PSVT terminal is at the edge of the HRPD network coverage and is 43 unable to support the PSVT session over the HRPD domain, the HRPD AN triggers the PSVT terminal to 44 attempt a domain transfer to the 1xCS network. The PSVT terminal shall drop the video media of the ongoing 45 PSVT session as described here while attempting a domain transfer (DT) to 1xCS network. 46 47 The PSVT terminal with an ongoing PSVT session shall follow the procedures defined in Section 4.5.1 (Figure 48 4.5-4) of [36] for domain transfer from the HRPD to 1xCS voice network. The video media of the PSVT 49 session shall be dropped / released after the VCC UE receives the HO stimulus8 as specified in step 1 of the call 50 flows in Section 4.5.1 of [36]. The PSVT terminal shall not send any signaling message indicating the release of 51 the video media of the ongoing PSVT session. Note that the video media shall be dropped prior to the 52 completion of step 10 of the call flows (Figure 4.5-4) described in section 4.5.1 of [36]. 53 54 55 56 57 8 58 The HRPD AN determines that the PSVT terminal is at the edge of the HRPD coverage and sends an 59 3G1xServices Message containing a 1x service redirection message to the PSVT terminal. The PSVT 60 terminal sends the HRPD 3G1xServicesAck message to the HRPD AN in acknowledgement.
42 3GPP2 C.S0055-A v1.0
1 11.4.2 PSVT HRPD voice to cdma2000 1xCS voice DT 2 3 4 The voice media component of the ongoing PSVT session is identical to the voice media component of a VoIP 5 over HRPD session. The inter-technology domain transfer call flows as described in section 4.5.1 and section 6 7 5.7.2 of [36] shall be followed to seamlessly handoff the voice component of a PSVT HRPD session to the 8 cdma2000 1xCS network. Note that section 5.7.4.3 of [2] describes how the SDP content of the SIP-re-INVITE 9 message sent from the VCC AS to the other end point (OEP) is created. An informative example is shown 10 below for the video related content of the SDP sent by the VCC AS during DT to OEP as described in [2]. 11 Example: 12 13 Original video related content of the SDP for the session prior to DT exchanged through the VCC AS (during 14 call setup): 15 16 17 m=video 51372 RTP/AVPF 98 18 a=rtpmap:98 H263-2000/90000 19 20 a=rtcp-fb:98 app apto-arr sendrecv 21 22 23 Video related content for the modified SDP Sent by VCC AS to OEP during DT as part of SIP-reINVITE: 24 m=video 0 RTP/AVPF 98 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
43
3GPP2 C.S0055-A v1.0
1 2 3 4 12 Annex A - QoS BLoB (Informative) 5 6 [17] defines the architecture and procedures for providing Quality of Service (QoS) support in 3GPP2 networks. 7 These procedures in [17] define the QoS BLoB which is used by the PSVT Terminal to request a QoS 8 reservation from the Radio Access Network. Table 3 provides an example of a requested QoS BloB to illustrate 9 how this BLoB may be used for PSVT. 10 11 12 13 Field Value Comment 14 15 16 QoS_BLOB_TYPE_IND 00 Default 17 18 QoS_BLOB_TYPE 001 Default 19 20 NUM_FLOWS` 110 6 flows 21 22 { Occurrence 1 23 24 FLOW_ID 00000001 Flow 1 25 26 27 Direction 00 Forward 28 29 OP_CODE 010 Add/Update only 30 31 R_QoS_SUB_BLOB_LEN 00000011 5 octets 32 33 R_QoS_SUB_BLOB 34 35 { 36 37 FLOWPRIORITY 0111 Priority 7 38 39 40 NUM_QoS_ATTRIBUTE_SETS 000 One less than 1 QoS_ATTRIBUTE_SET 41 42 { 43 44 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 45 46 QoS_ATTRIBUTE_SET 47 48 QoS_ATTRIBUTE_SET_ID 0000001 Set ID to 1 49 50 51 VERBOSE 0 Use ProfileID 52 53 FlowProfileID 00000010100000000 0x0500 –conversational media control 54 signaling 55 56 } 57 58 Reserved 00000 To make the R_QoS_SUB_BLOB 59 exactly five octets long 60
44 3GPP2 C.S0055-A v1.0
1 2 } 3 4 } 5 6 { Occurrence 2 7 8 FLOW_ID 00000010 Flow 2 9 10 11 Direction 00 Forward 12 13 OP_CODE 010 Add/Update only 14 15 R_QoS_SUB_BLOB_LEN 00000011 5 octets 16 17 R_QoS_SUB_BLOB 18 19 { 20 21 FLOWPRIORITY 0110 Priority 6 22 23 24 NUM_QoS_ATTRIBUTE_SETS 000 One less than 1 QoS_ATTRIBUTE_SET 25 26 { 27 28 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 29 30 QoS_ATTRIBUTE_SET 31 32 QoS_ATTRIBUTE_SET_ID 0000001 Set ID to 1 33 34 35 VERBOSE 0 Use ProfileID 36 37 FlowProfileID 00000000100000000 0x0100 –conversational rate set 1 38 interactive speech, full rate with no 39 frame bundling 40 41 } 42 43 Reserved 00000 To make the R_QoS_SUB_BLOB 44 exactly five octets long 45 46 } 47 48 49 } 50 51 { Occurrence 3 52 53 FLOW_ID 00000011 Flow 3 54 55 Direction 00 Forward 56 57 OP_CODE 010 Add/Update only 58 59 60
45
3GPP2 C.S0055-A v1.0
1 2 3 R_QoS_SUB_BLOB_LEN 0001000 8 octets 4 5 R_QoS_SUB_BLOB 6 7 { 8 9 FLOWPRIORITY 0111 Priority 7 10 11 NUM_QoS_ATTRIBUTE_SETS 001 One less than 2 12 13 QoS_ATTRIBUTE_SETs 14 15 { 16 17 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 18 19 QoS_ATTRIBUTE_SET 20 21 QoS_ATTRIBUTE_SET_ID 0000001 Set ID to 1 22 23 VERBOSE 0 Use ProfileID 24 25 26 FlowProfileID 0000001100000011 0x0303 –conversational interactive 27 video 48 kbps 28 29 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 30 31 QoS_ATTRIBUTE_SET 32 33 QoS_ATTRIBUTE_SET_ID 0000010 Set ID to 2 34 35 VERBOSE 0 Use ProfileID 36 37 38 FlowProfileID 0000001100000001 0x0301 –conversational interactive 39 video 32 kbps 40 41 } 42 43 Reserved 0 To make the R_QoS_SUB_BLOB 44 exactly eight octets long 45 46 } 47 48 } 49 50 51 { Occurrence 4 52 53 FLOW_ID 00000100 Flow 4 54 55 Direction 01 Reverse 56 57 OP_CODE 010 Add/Update only 58 59 R_QoS_SUB_BLOB_LEN 00000011 5 octets 60
46 3GPP2 C.S0055-A v1.0
1 2 R_QoS_SUB_BLOB 3 4 { 5 6 FLOWPRIORITY 0111 Priority 7 7 8 NUM_QoS_ATTRIBUTE_SETS 000 One less than 1 QoS_ATTRIBUTE_SET 9 10 11 { 12 13 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 14 15 QoS_ATTRIBUTE_SET 16 17 QoS_ATTRIBUTE_SET_ID 0000001 Set ID to 1 18 19 VERBOSE 0 Use ProfileID 20 21 FlowProfileID 00000010100000000 0x0500 –conversational media control 22 23 signaling 24 25 } 26 27 Reserved 00000 To make the R_QoS_SUB_BLOB 28 exactly five octets long 29 30 } 31 32 } 33 34 { Occurrence 5 35 36 37 FLOW_ID 00000101 Flow 5 38 39 Direction 01 Reverse 40 41 OP_CODE 010 Add/Update only 42 43 R_QoS_SUB_BLOB_LEN 00000011 5 octets 44 45 R_QoS_SUB_BLOB 46 47 48 { 49 50 FLOWPRIORITY 0110 Priority 6 51 52 NUM_QoS_ATTRIBUTE_SETS 000 One less than 1 QoS_ATTRIBUTE_SET 53 54 { 55 56 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 57 58 QoS_ATTRIBUTE_SET 59 60
47
3GPP2 C.S0055-A v1.0
1 2 3 QoS_ATTRIBUTE_SET_ID 0000001 Set ID to 1 4 5 VERBOSE 0 Use ProfileID 6 7 FlowProfileID 00000000100000000 0x0100 –conversational rate set 1 8 interactive speech, full rate with no 9 frame bundling 10 11 } 12 13 14 Reserved 00000 To make the R_QoS_SUB_BLOB 15 exactly five octets long 16 17 } 18 19 } 20 21 { Occurrence 6 22 23 FLOW_ID 00000110 Flow 6 24 25 26 Direction 01 Reverse 27 28 OP_CODE 010 Add/Update only 29 30 R_QoS_SUB_BLOB_LEN 0001000 8 octets 31 32 R_QoS_SUB_BLOB 33 34 { 35 36 FLOWPRIORITY 0111 Priority 7 37 38 39 NUM_QoS_ATTRIBUTE_SETS 001 One less than 2 40 QoS_ATTRIBUTE_SETs 41 42 { 43 44 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 45 46 QoS_ATTRIBUTE_SET 47 48 QoS_ATTRIBUTE_SET_ID 0000001 Set ID to 1 49 50 51 VERBOSE 0 Use ProfileID 52 53 FlowProfileID 0000001100000011 0x0303 –conversational interactive video 54 48 kbps 55 56 QoS_ATTRIBUTE_SET_LEN 0011 3 octets 57 58 QoS_ATTRIBUTE_SET 59 60
48 3GPP2 C.S0055-A v1.0
1 2 QoS_ATTRIBUTE_SET_ID 0000010 Set ID to 2 3 4 VERBOSE 0 Use ProfileID 5 6 FlowProfileID 0000001100000001 0x0301 –conversational interactive video 7 32 kbps 8 9 } 10 11 12 Reserved 0 To make the R_QoS_SUB_BLOB 13 exactly eight octets long 14 15 } 16 17 } 18 19 20 21 Table 3 Example of Request QoS BLoB 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
49
3GPP2 C.S0055-A v1.0
1 2 3 No Text 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
50 3GPP2 C.S0055-A v1.0
1 2 3 13 Annex B - Call Flow Examples for Supplementary 4 Services and Functions (Informative) 5 6 7 This section describes supplementary services for PSVT. Support of these services is optional. 8 9 In all the call flows in this section the following applies: 10 11 • For PSVT over IMS, the IMS CN refers to the IP Multimedia Subsystem core network and includes 12 the P-CSCF, S-CSCF, and I-CSCF’s of both PSVT Terminal 1 and PSVT Terminal 2. 13 14 15 • For non-IMS PSVT, the IMS CN refers to the SIP proxies of PSVT Terminal 1 and PSVT Terminal 2. 16 17 18 19 13.1 PSVT Voice Retry 20 21 22 When a PSVT Terminal attempts to originate or receive a PSVT call it may be unable to establish a PSVT 23 session due to the lack of network QoS resources. When this happens a PSVT Terminal may reattempt the call 24 as a voice-only call. The means by which the PSVT Terminal is preconfigured to reattempt a voice-only call is 25 outside of the scope of this document (e.g., prompting the user or pre-selection by the user). 26 27 This section provides call flows describing how the PSVT Voice Retry feature can be performed under different 28 call scenarios. 29 30 13.1.1 Retry PSVT Call Origination as VoIP 31 32 33 The following call flow describes the procedures when a PSVT Terminal attempting to originate a PSVT call is 34 granted QoS for only the voice media and retries a VoIP call. This call flow illustrates how the feature can be 35 performed if “PSVT Retry as VoIP” is supported by the originating 3GPP2 PSVT Terminal. 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
51
3GPP2 C.S0055-A v1.0
1 2 3 PSVT Terminal PSVT Terminal RAN IMS CN 4 1 2 5 6 7 8 9 1. Activate QoS for 10 voice and video 11 12 13 14 2. QoS for voice 15 granted, QoS for video 16 not granted 17 18 19 3. INVITE (voice SDP offer) 20 4. INVITE (voice SDP offer) 100 Trying 21 100 Trying 22 23 24 5. Activate QoS 25 for voice flow 26 27 6. 180 Ringing (voice SDP answer) 28 29 30 31 32 33 The remaining steps follow the call flow for normal call set-up 34 35 36 37 Figure 14 Call Flow for Retry PSVT Call Origination as VoIP 38 39 Step 1 40 41 The originating PSVT Terminal requests the Radio Access Network to activate its QoS reservations for the 42 voice and video flows before initiating the PSVT call. 43 44 Step 2 45 46 47 The Radio Access Network activates the QoS reservation for voice but does not grant the QoS reservation for 48 video. This can occur according to one of the following procedures: 49 50 • The Radio Access Network activates the QoS for voice but does not grant the QoS for video. 51 52 • The Radio Access Network does not grant the QoS reservations for both voice and video. PSVT 53 Terminal 1 then requests activation of QoS for voice only which the Radio Access Network then 54 grants. 55 56 Step 3 57 58 59 60
52 3GPP2 C.S0055-A v1.0
1 The user of PSVT Terminal 1 has previously selected or immediately selects the “PSVT Voice Retry” mode of 2 operation. PSVT Terminal 1 attempts to complete a Voice-over-IP call using the activated QoS reservation for 3 voice. 4 5 PSVT Terminal 1 constructs a SIP INVITE request and send this to the P-CSCF of PSVT Terminal 1. The SDP 6 7 parameters in the SIP INVITE do not include the video media (m=) line. Additional SDP parameters may be 8 included to establish the Voice-over-IP session. 9 10 Step 4 11 12 The P-CSCF sends a 100 Trying response to the INVITE. The IMS CN performs processing of the INVITE 13 request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. The S-CSCFs in 14 either CN and/or application servers in the request path might perform service/call control. 15 16 Upon receiving the SIP INVITE, PSVT Terminal 2 immediately sends a 100 trying response to suppress 17 retransmissions of the INVITE by the P-CSCF. 18 19 Step 5 20 21 Upon receiving the INVITE request PSVT Terminal 2 activates the QoS reservation for the voice flow that is 22 required to support the voice codec selected by PSVT Terminal 2. 23 24 25 Step 6 26 27 The rest of the call progresses according to the call flow defined in section 5.2.1, starting at step 5. The only 28 exceptions are, 29 30 • At step 5, the SDP answer from PSVT Terminal 2 only includes parameters relevant to the Voice-over- 31 IP session. 32 33 • At step 18 only RTP voice traffic is exchanged. 34 35 13.1.2 Retry PSVT Call Reception as VoIP 36 37 38 The following call flow describes the procedures when a PSVT Terminal attempting to receive a PSVT call is 39 granted QoS for only the voice media and retries a VoIP call. This call flow illustrates how the “PSVT Voice 40 Retry” feature can be performed if “PSVT Retry as VoIP” is supported by the called 3GPP2 PSVT Terminal. 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
53
3GPP2 C.S0055-A v1.0
1 2 3 PSVT Terminal PSVT Terminal IMS CN RAN 4 1 2 5 6 7 8 1. Activate QoS for voice and 9 video flows 10 11 2. INVITE (SDP offer) 3. INVITE (SDP offer) 12 100 Trying 13 100 Trying 14 15 4. Activate QoS for voice 16 and video flows 17 18 19 20 5. QoS for voice 21 granted, QoS for video 22 not granted 23 24 6. 180 Ringing (voice SDP answer) 25 7. 180 Ringing (voice SDP answer) 26 27 28 8. Generate Ringback 29 9. Deactivate QoS 30 for video flow 31 10. PRACK 32 33 34 The remaining steps follow the call flow for normal call set-up 35 36 37 Figure 15 Call Flow for Retry PSVT Call Reception as VoIP 38 39 40 41 Step 1 42 43 The originating PSVT Terminal activates its QoS reservations for the voice and video flows before initiating the 44 45 PSVT call. The IMS CN refers to the IP Multimedia Subsystem core network and includes the P-CSCF, S- 46 CSCF, and I-CSCF’s of both PSVT Terminal 1 and PSVT Terminal 2. 47 48 Step 2 49 50 After or during the QoS activation in step 1, the originating PSVT Terminal constructs a SIP INVITE request 51 and sends this to the P-CSCF of PSVT Terminal 1. The SDP parameters to be included in the SIP INVITE are 52 specified in section 5.5.1. 53 54 Step 3 55 56 The P-CSCF sends a 100 Trying response to the INVITE. The IMS CN performs processing of the INVITE 57 request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. The S-CSCFs in 58 either CN and/or application servers in the request path might perform service/call control. 59 60
54 3GPP2 C.S0055-A v1.0
1 Upon receiving the SIP INVITE, PSVT Terminal 2 immediately sends a 100 trying response to suppress 2 retransmissions of the INVITE by the P-CSCF. 3 4 Step 4 5 6 7 Upon receiving the INVITE request PSVT Terminal 2 requests the Radio Access Network to activate its QoS 8 reservations for the voice and video flows that are required to support the media codecs selected by PSVT 9 Terminal 2. 10 11 Step 5 12 13 The Radio Access Network activates the QoS reservation for voice but does not grant the QoS reservation for 14 video. This can occur according to one of the following procedures: 15 16 • The Radio Access Network activates the QoS for voice but does not grant the QoS for video. 17 18 • The Radio Access Network does not grant the QoS reservations for both voice and video. PSVT 19 Terminal 2 then requests activation of QoS for voice only which the Radio Access Network then 20 grants. 21 22 23 Step 6 24 25 The user of PSVT Terminal 2 has previously selected or immediately selects the “PSVT Voice Retry” mode of 26 operation. PSVT Terminal 2 attempts to complete a Voice-over-IP call using the activated QoS reservation for 27 voice. 28 29 Since the resource reservation on both sides is complete, PSVT Terminal 2 constructs a 180 Ringing response 30 consisting of an SDP answer and sends this reliably to the P-CSCF of PSVT Terminal 2. The SDP answer 31 includes the parameters specified in 5.5.2 and sets the port number for the video media (m=) line to zero. 32 Additional SDP parameters may be included to establish the Voice-over-IP session. 33 34 PSVT Terminal 2 is ready to receive media at this time. 35 36 Step 7 37 38 39 The IMS CN performs processing of the 180 Ringing response and ultimately routes it to PSVT Terminal 2 via 40 the IMS CN of PSVT Terminal 2. The S-CSCFs in either CN and/or application servers in the response path 41 might perform service/call control. 42 43 The user of PSVT Terminal 1 has previously selected or immediately selects the “PSVT Voice Retry” mode of 44 operation. PSVT Terminal 1 attempts to complete a Voice-over-IP call using the activated QoS reservation for 45 voice and is ready to receive media at this time. 46 47 Step 8 48 49 Upon receiving the 180 Ringing response PSVT Terminal 1 plays a ringtone (ringback) locally. 50 51 Step 9 52 53 PSVT Terminal 1 deactivates its QoS for the video flow. This can be performed at the same time as step 8. 54 55 56 Step 10 57 58 The rest of the call progresses according to the call flow defined in section 5.2.1, starting at step 8. The only 59 exception is that at step 18 only RTP voice traffic is exchanged. 60
55
3GPP2 C.S0055-A v1.0
1 2 13.1.3 Retry PSVT Call Origination as 1x Circuit-Switched Voice 3 4 5 The following call flow describes the procedures when a PSVT Terminal attempting to originate a PSVT call is 6 not granted QoS for voice and video media, and retries a 1x CS voice call. This call flow illustrates how the 7 “PSVT Voice Retry” feature is performed if “PSVT Retry as 1x CS Voice” is supported by the originating 8 3GPP2 PSVT Terminal. 9 10 11 12 PSVT Terminal RAN 13 1 14 15 16 17 18 19 20 1. Activate QoS for voice and video 21 22 23 24 25 26 27 28 2. QoS for voice/video not granted 29 30 31 32 33 34 35 36 3. Originate 1x circuit-switched voice service option 37 38 39 40 41 42 43 Remaining steps follow procedures for establishing 44 a 1x circuit switched voice service option 45 46 47 48 49 50 51 Figure 16 Call Flow for Retry PSVT Call Origination as 1x CS Voice 52 53 Step 1 54 55 The originating PSVT Terminal requests the Radio Access Network to activate its QoS reservations for the 56 voice and video flows before initiating the PSVT call. 57 58 Step 2 59 60
56 3GPP2 C.S0055-A v1.0
1 If PSVT Terminal 1 supports both “PSVT Retry as VoIP” and “PSVT Retry as 1x CS Voice” this step consists 2 of the following events: 3 4 The Radio Access Network does not grant the QoS reservations for both voice and video. The user of PSVT 5 Terminal 1 has previously selected or immediately selects the “PSVT Voice Retry” mode of operation. PSVT 6 7 Terminal 1 then requests a QoS reservation for voice only which is also not granted by the Radio Access 8 Network. 9 10 If PSVT Terminal 1 only supports “PSVT Retry as 1x CS Voice” then this step consists of the following events: 11 12 The Radio Access Network does not grant the QoS reservations for voice, video, or both voice and video. The 13 user of PSVT Terminal 1 has previously selected or immediately selects the “PSVT Voice Retry” mode of 14 operation. 15 16 Step 3 17 18 If PSVT Terminal 1 knows the telephone number or tel URI of PSVT Terminal 2, PSVT Terminal 1 originates 19 a 1x Circuit-Switched voice call to PSVT Terminal 2 using a 1x voice service option. 20 21 The remaining steps follow procedures for establishing a 1x voice service option. 22 23 24 13.1.4 Retry PSVT Call Reception as 1x Circuit-Switched Voice 25 26 The following call flow describes the procedures when a PSVT Terminal attempting to receive a PSVT call is 27 not granted QoS for both the voice and video media, and retries a 1x CS voice call. This call flow illustrates 28 how the “PSVT Voice Retry” feature can be performed when “PSVT Retry as 1x CS Voice” is supported by the 29 called 3GPP2 PSVT Terminal. The calling PSVT Terminal in this call flow attempts “PSVT Retry as VoIP.” 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
57
3GPP2 C.S0055-A v1.0
1 2 3 PSVT PSVT IMS CN RAN 4 Terminal 1 Terminal 2 5 6 7 8 1. Activate QoS 9 for voice and 10 video flows 11 2. INVITE (SDP offer) 12 3. INVITE (SDP offer) 13 100 Trying 100 Trying 14 15 16 4. Activate QoS for voice 17 and video flows 18 19 20 21 22 5. QoS for voice/video 23 not granted 24 25 26 6. 302 Moved Temporarily 27 7. 302 Moved Temporarily 28 29 8. Deactivate QoS for 30 video flow, maintain 31 QoS for voice flow 32 33 34 9. INVITE (Voice SDP offer) 35 100 Trying 36 37 Remaining steps follow procedures for 38 establishing Remaining steps follow procedures for 39 1x circuit switched voice service call establishing VoIP call 40 41 42 43 44 Figure 17 Call Flow for Retry PSVT Call Reception as 1x CS Voice 45 46 Step 1 47 48 The originating PSVT Terminal activates its QoS reservations for the voice and video flows before initiating the 49 PSVT call. The IMS CN refers to the IP Multimedia Subsystem core network and includes the P-CSCF, S- 50 CSCF, and I-CSCF’s of both PSVT Terminal 1 and PSVT Terminal 2. 51 52 Step 2 53 54 After or during the QoS activation in step 1, the originating PSVT Terminal constructs a SIP INVITE request 55 and sends this to the P-CSCF of PSVT Terminal 1. The SDP parameters to be included in the SIP INVITE are 56 specified in section 5.5.1. 57 58 59 Step 3 60
58 3GPP2 C.S0055-A v1.0
1 The P-CSCF sends a 100 Trying response to the INVITE. The IMS CN performs processing of the INVITE 2 request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. The S-CSCFs in 3 either CN and/or application servers in the request path might perform service/call control. 4 5 Upon receiving the SIP INVITE, PSVT Terminal 2 immediately sends a 100 trying response to suppress 6 7 retransmissions of the INVITE by the P-CSCF. 8 9 Step 4 10 11 Upon receiving the INVITE request PSVT Terminal 2 requests the Radio Access Network to activate its QoS 12 reservations for the voice and video flows that are required to support the media codecs selected by PSVT 13 Terminal 2. 14 15 Step 5 16 17 If PSVT Terminal 2 supports both “PSVT Retry as VoIP” and “PSVT Retry as 1x CS Voice” this step consists 18 of the following events: 19 20 The Radio Access Network does not grant the QoS reservations for both voice and video. The user of PSVT 21 Terminal 2 has previously selected or immediately selects the “PSVT Voice Retry” mode of operation. PSVT 22 Terminal 2 then requests a QoS reservation for voice only which is also not granted by the Radio Access 23 Network. 24 25 26 If PSVT Terminal 1 only supports “PSVT Retry as 1x CS Voice” then this step consists of the following events: 27 28 The Radio Access Network does not grant the QoS reservations for voice, video, or both voice and video. The 29 user of PSVT Terminal 2 has previously selected or immediately selects the “PSVT Voice Retry” mode of 30 operation. 31 32 Step 6 33 34 The user of PSVT Terminal 2 has previously selected or immediately selects the “PSVT Voice Retry” mode of 35 operation and PSVT Terminal 2 supports 1x voice service options. PSVT Terminal 2 sends a 302 “Moved 36 Temporarily” response to the IMS CN and includes its tel URI in the Contact header field of the response. 37 38 Step 7 39 40 The IMS CN routes the 302 Moved Temporarily response to PSVT Terminal 1. 41 42 43 Step 8 44 45 The user of PSVT Terminal 1 has previously selected or immediately selects the “PSVT Voice Retry” mode of 46 operation. PSVT Terminal 1 deactivates the QoS reservation for video and maintains the QoS reservation for 47 voice. 48 49 Step 9 50 51 PSVT Terminal 1 originates a VoIP call to the telephone number of PSVT Terminal 2. PSVT Terminal 1 52 constructs a SIP INVITE request and send this to the P-CSCF of PSVT Terminal 1. The SDP parameters in the 53 SIP INVITE do not include the video media (m=) line. Additional SDP parameters may be included to 54 establish the Voice-over-IP session. 55 56 The remaining steps between PSVT Terminal 1 and the IMS CN follow the procedures for establishing a VoIP 57 call (after Step 3 in section 5.6.1). Upon receiving the INVITE request addressed to the telephone number of 58 PSVT Terminal 2, the IMS CN establishes a 1x circuit-switched voice call to PSVT Terminal 2. The IMS CN 59 60
59
3GPP2 C.S0055-A v1.0
1 2 performs the necessary interworking between the VoIP segment and 1x circuit-switched segment of the voice 3 call. 4 5 6 13.2 Video/Media on Hold 7 8 This feature allows the user to temporarily pause the video and/or voice transmission/reception during a PSVT 9 session. The call flow in Figure 18 illustrates the case where PSVT Terminal 1 places only video transmission 10 and reception on hold. This call flow can be easily modified to describe the case where only voice transmission 11 and reception are placed on hold by interchanging the procedures applied to the voice and video media streams. 12 13 14 While the call is on hold the PSVT Terminal does not deactivate the QoS reservation(s) for the media stream(s) 15 placed on hold. This allows the terminals to quickly resume transmission and reception of the media when the 16 user requests it. 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
60 3GPP2 C.S0055-A v1.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 Figure 18 Call Flow for Video on Hold Feature 53 54 Step 1 55 56 The two terminals are involved in a PSVT call and are actively exchanging bi-directional RTP voice and video 57 media. 58 59 Step 2 60
61
3GPP2 C.S0055-A v1.0
1 2 The user of PSVT Terminal 1 decides to place the video transmission and reception on hold. 3 4 Step 3 5 6 PSVT Terminal 1 constructs a SIP re-INVITE request and send this to the P-CSCF of PSVT Terminal 1. The 7 SDP parameters to be included in the SIP re-INVITE are as specified in 5.5.1with the exception that the 8 9 a=inactive parameter replaces the a=sendrecv parameters under the video media (m=) line. PSVT Terminal 1 10 continues to use the same audio media (m=) line from the previously negotiated SDP to prevent interruption in 11 the voice media decoding. 12 13 Step 4 14 15 The P-CSCF sends a 100 Trying response to the re-INVITE. The IMS CN performs processing of the re- 16 INVITE request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. 17 18 Step 5 19 20 Upon receiving the re-INVITE request, PSVT Terminal 2 notifies its user that the video media is being placed 21 on hold. 22 23 Step 6 24 25 26 PSVT Terminal 2 responds with a 200 OK that contains the SDP Answer parameters specified in 5.5.2 with the 27 exception that the a=inactive parameter replaces the a=sendrecv parameters under the video media (m=) line. 28 29 PSVT Terminal 2 immediately stops sending and decoding video media. PSVT Terminal 2 continues to send 30 and decode voice media. 31 32 Step 7 33 34 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. Upon receiving the 200 OK response, 35 PSVT Terminal 1 immediately stops sending and decoding video media. PSVT Terminal 1 continues to send 36 and decode voice media. 37 38 Step 8 39 40 PSVT Terminal 1 sends an ACK request to acknowledge the 200 OK 41 42 43 Step 9 44 45 The IMS CN forwards the ACK to PSVT Terminal 2. 46 47 Step 10 48 49 Terminals 1 and 2 continue to exchange bidirectional RTP voice using the negotiated codecs. 50 51 Step 11 52 53 The user of PSVT Terminal 1 decides to resume the video transmission and reception. 54 55 Step 12 56 57 After the QoS activation, PSVT Terminal 1 constructs a SIP re-INVITE request and sends this to the P-CSCF of 58 59 PSVT Terminal 1. The SDP parameters to be included in the SIP INVITE is as specified in section 5.5.1, 60
62 3GPP2 C.S0055-A v1.0
1 including the a=sendrecv parameters. PSVT Terminal 1 continues to use the same audio media (m=) line from 2 the previously negotiated SDP to prevent interruption in the voice media decoding. 3 4 Step 13 5 6 7 The P-CSCF sends a 100 Trying response to the re-INVITE. The IMS CN performs processing of the re- 8 INVITE request and ultimately routes it to PSVT Terminal 2 via the IMS CN of PSVT Terminal 2. 9 10 Upon receiving the SIP re-INVITE, PSVT Terminal 2 immediately sends a 100 trying response to suppress 11 retransmissions of the re-INVITE by the P-CSCF. 12 13 Step 14 14 15 PSVT Terminal 2 responds with a 200 OK that contains the SDP Answer parameters specified in 5.5.2, 16 including the a=sendrecv parameters. PSVT Terminal 2 is ready to receive video media at this time. 17 18 Step 15 19 20 The 200 OK response is forwarded by the IMS CN to PSVT Terminal 1. After receiving the 200 OK response 21 PSVT Terminal 1 is ready to receive video media and may begin sending video media. 22 23 24 When PSVT Terminal 1 starts sending video media it immediately sends an RTCP Sender Report for the video 25 media to PSVT Terminal 2. This will allow PSVT Terminal 2 to quickly synchronize the received video stream 26 with the voice stream. 27 28 Step 16 29 30 PSVT Terminal 1 sends ACK request to acknowledge the 200 OK. 31 32 Step 17 33 34 The IMS CN forwards the ACK to PSVT Terminal 2. PSVT Terminal 2 may begin sending video media after 35 receiving the ACK. 36 37 When PSVT Terminal 2 starts sending video media it immediately sends RTCP Sender Reports for both the 38 video and voice media to PSVT Terminal 1. This allows PSVT Terminal 1 to quickly synchronize the received 39 video stream with the voice stream. PSVT Terminal 1 also sends RTCP Sender Reports for both the video and 40 41 voice media when PSVT Terminal 1 starts sending video media to PSVT Terminal 2. 42 43 Step 18 44 45 PSVT Terminal 1 and PSVT Terminal 2 exchange bidirectional RTP voice and video using the negotiated 46 codecs. 47 48 49 50 51 52 53 54 55 56 57 58 59 60
63
3GPP2 C.S0055-A v1.0
1 2 3 4 14 ANNEX C - SDP Offer/Answer Examples for the 5 b=AS and b=TIAS SDP Parameters (Informative) 6 7 8 Following are some examples of SDP exchanges for PSVT calls following the procedures described in sections 9 5.5 and 7. For setting the b=AS parameter in these examples it is assumed that ROHC is not enabled and the 10 RTP/UDP/IP headers consume an additional 9.6 kbps for video streams and 16 kbps for voice streams. The 11 b=TIAS parameter is set to the data rate specified for the FlowProfileID [40] negotiated by the PSVT Terminal 12 with its Radio Access Network. 13 14 Example 1: Signaling of QoS requirements where both terminals can receive media at the same rates on their 15 forward links. 16 17 The offering terminal establishes voice FlowProfileID 256 (conversational RS1, interactive speech, full rate 18 with no frame bundling) and video FlowProfileID 773 (64 kbps conversational interactive video) on the forward 19 link with its RAN. The offering terminal offers DTMF and two speech codecs: EVRC and EVRC-B. 20 Media Section of SDP Offer: 21 22 m=audio 20000 RTP/AVP 96 97 98 23 24 b=AS:25 25 b=TIAS:8550 26 27 a=rtpmap:96 EVRCB0/8000 28 a=rtpmap:97 EVRC0/8000 29 30 a=rtpmap:98 telephone-event/8000 31 m=video 20000 RTP/AVP 99 32 33 b=AS:74 34 35 b=TIAS:64000 36 a=rtpmap:99 H263-1998/90000 37 38 The answering terminal assumes that the offering terminal will transmit voice and video media at the same rate 39 at which it can receive (i.e., 8.55 kbps and 64 kbps, respectively). The answering terminal assumes the highest 40 average rate for the voice media, requesting FlowProfileID 256. The answering terminal is successful at 41 establishing the same FlowProfileID values with the forward link of its RAN: 256 for voice and 773 for video. 42 43 Media Section of SDP Answer: 44 m=audio 30000 RTP/AVP 96 98 45 46 b=AS:25 47 b=TIAS:8550 48 49 a=rtpmap:96 EVRCB0/8000 50 a=rtpmap:98 telephone-event/8000 51 52 m=video 30000 RTP/AVP 99 53 54 b=AS:74 55 b=TIAS:64000 56 57 a=rtpmap:99 H263-1998/90000 58 59 Example 2: Signaling of QoS reservations where both terminals can receive media at different rates on their 60 forward links.
64 3GPP2 C.S0055-A v1.0
1 Following the case in example 1, the offering terminal establishes voice FlowProfileID 256 (conversational 2 RS1, interactive speech, full rate with no frame bundling) and video FlowProfileID 773 (64 kbps conversational 3 interactive video) on the forward link with its RAN. The offering terminal offers DTMF and two speech 4 codecs: EVRC and EVRC-B. The media section of the SDP offer is the same as in example 1. 5 6 7 The answering terminal assumes that the offering terminal will transmit voice and video media at the same rate 8 at which it can receive (i.e., 8.55 kbps and 64 kbps, respectively) and requests appropriate FlowProfileIDs from 9 its RAN. The RAN grants the requested voice FlowProfileID 256 but only provides 48 kbps for video (by 10 granting FlowProfileID 771). 11 Media Section of SDP Answer: 12 13 m=audio 30000 RTP/AVP 96 98 14 b=AS:25 15 16 b=TIAS:8550 17 18 a=rtpmap:96 EVRCB0/8000 19 a=rtpmap:98 telephone-event/8000 20 21 m=video 30000 RTP/AVP 99 22 b=AS:58 23 24 b=TIAS:48000 25 a=rtpmap:99 H263-1998/90000 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
65