Interoperability Standards for VoIP ATM Components - … · The document ED-137 Volume 1...

92240 MALAKOFF, France Fax: 33 1 46 55 62 65Web Site: www.eurocae.net Email: [email protected]

102 rue Etienne Dolet Tel: 33 1 40 92 79 30

INTEROPERABILITY STANDARDS FOR VOIP ATM COMPONENTS

VOLUME 1: RADIO

This document is the exclusive intellectual and commercial property of EUROCAE. It is presently commercialised by EUROCAE.

This electronic copy is delivered to your company/organisation for internal use exclusively. In no case it must be re-sold, or hired, lent or exchanged outside your company.

ED-137/1B January 2012

The European Organisation for Civil Aviation Equipment L’Organisation Européenne pour l’Equipement de l’Aviation Civile


VOLUME 1: RADIO




i

FOREWORD

1. The document ED-137 Volume 1 “Interoperability Standards for VoIP ATM Radio Components” was prepared by EUROCAE Working Group 67 and was accepted by the Council of EUROCAE on 19 January 2012.

2. EUROCAE is an international non-profit making organisation. Membership is open to manufacturers and users in Europe of equipment for aeronautics, trade associations, national civil aviation administrations and non-European organisations. Its work programme is principally directed to the preparation of performance specifications and guidance documents for civil aviation equipment, for adoption and use at European and world-wide levels.

3. The findings of EUROCAE are resolved after discussion among its members and, where appropriate, in collaboration with RTCA Inc, Washington D.C. USA and/or the Society of Automotive Engineers (SAE), Warrendale, PA, USA through their appropriate committee.

4. This document is part of a series of EUROCAE Documents, composed of 5 volumes: • ED-137/1 “Interoperability Standard for VOIP ATM Components –

Volume 1: Radio” • ED-137/2 “Interoperability Standard for VOIP ATM Components –

Volume 2: Telephone” • ED-137/3 “Interoperability Standard for VOIP ATM Components –

Volume 3: European Legacy Telephone Interworking” • ED-137/4 “Interoperability Standard for VOIP ATM Components –

Volume 4: Recording” • ED-137/5 “Interoperability Standard for VOIP ATM Components –

Volume 5: Supervision”. Together the 5 volumes, edition B, replace ED-137A, published in September 2010.

5. This version of the document represents “the minimum specification required for Manufacturers and Users to assure Interoperability between VoIP ATM Radio Components”. EUROCAE WG67 has updated the previous version of ED137A and created a separated document ED 137 Volume 1 replacing the Part 1 of ED137A, referenced in ICAO document 9896: • following a series of plug tests, performed by many suppliers in Arlington

in May 2011 and in Sophia Antipolis in June 20112010, improving ED-137 concerning the understanding of interoperability requirements between the ATM VoIP components,

• following discussions with FAA for taking into account US requirements agreeable within the European context.

6. This version is taking into account the EUROCONTROL VoIP in ATM Test Case Specification.

7. EUROCAE performance specifications are recommendations only. EUROCAE is not an official body of the European governments; its recommendations are valid statements of official policy only when adopted by a particular government or conference of governments.

8. Copies of this document may be obtained from: EUROCAE

102 rue Etienne Dolet 92240 MALAKOFF

France Tel: 33 1 40 92 79 30 Fax: 33 1 46 55 62 65

Email: [email protected] Web Site: www.eurocae.net

© EUROCAE, 2011

mailto:[email protected]

http://www.eurocae.net/

ii

TABLE OF CONTENTS FOREWORD ................................................................................................................................... i CHAPTER 1 INTRODUCTION .................................................................................................. 1

1.1 BACKGROUND...................................................................................... 1 1.2 ED-137 Volume 1 PRESENTATION...................................................... 3 1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS AND

OPTIONS ............................................................................................... 3 1.4 VERSION TRACKING............................................................................ 4

CHAPTER 2 RADIO COMMUNICATION MODEL ..................................................................... 5 2.1 DEFINITIONS......................................................................................... 5 2.2 PROTOCOL STACK .............................................................................. 8 2.3 BASIC PROTOCOL REQUIREMENTS ................................................. 8 2.4 MODES OF OPERATION ...................................................................... 9

2.4.1 Real time Transport Protocol (RTP) and Real time Transport Header Extension.................................................................... 9

2.4.2 Combined GRS configuration ................................................. 10 2.4.3 Separated GRS configuration ................................................. 11

CHAPTER 3 PROFILE STANDARD FOR THE USE OF SIP IN AN AGVN............................... 13 3.1 SESSION INITIATION PROTOCOL ...................................................... 13 3.2 LOGICAL ATS-SIP ENTITIES................................................................ 13 3.3 SUPPORTED REQUESTS .................................................................... 13

3.3.1 INVITE and RE-INVITE........................................................... 14 3.3.2 ACK......................................................................................... 14 3.3.3 CANCEL.................................................................................. 14 3.3.4 BYE ......................................................................................... 14 3.3.5 REGISTER.............................................................................. 15 3.3.6 WG67 KEY-IN Event Package................................................ 15

3.4 SUPPORTED RESPONSES.................................................................. 16 3.4.1 1xx Provisional Responses..................................................... 17 3.4.2 2xx Successful Responses ..................................................... 18 3.4.3 3xx Redirection Responses .................................................... 18 3.4.4 4xx Client Failure Responses ................................................. 18 3.4.5 5xx Server Error Responses................................................... 19 3.4.6 6xx Global Failure Responses ................................................ 19

3.5 SUPPORTED HEADER FIELDS ........................................................... 19 3.5.1 User Agent Request Headers ................................................. 19 3.5.2 User Agent Response Headers .............................................. 21

3.6 SDP MESSAGE BODY .......................................................................... 23 3.6.1 SDP Message body attributes ................................................ 25

3.7 ADDRESS FORMAT.............................................................................. 31 3.8 SIP CONNECTION FACILITIES ............................................................ 31

3.8.1 Basic call functionalities .......................................................... 31 3.8.2 Interaction with Other ATS Supplementary Services.............. 33 3.8.3 AUDIBLE TONES ................................................................... 34 3.8.4 SIP Radio Session establishment Procedure ......................... 34 3.8.5 SIP Radio Session request verification................................... 36

© EUROCAE, 2012

iii

CHAPTER 4 AUDIO.................................................................................................................... 38 4.1 INTRODUCTION.................................................................................... 38 4.2 AUDIO SPECIFICATION ....................................................................... 38

4.2.1 Audio Level ............................................................................. 38 4.2.2 Audio Quality........................................................................... 38 4.2.3 Voice Coding........................................................................... 39

4.3 GUIDELINES FOR SAMPLE-BASED AUDIO CODECS....................... 39 4.4 AUDIO CODECS.................................................................................... 39

CHAPTER 5 RTP: REAL-TIME TRANSPORT PROTOCOL...................................................... 40 5.1 REAL-TIME TRANSPORT PROTOCOL - GENERAL ISSUES............. 40

5.1.1 Basic System Topology .......................................................... 40 5.1.2 RTP-Payload Types compliant with RFC 3551 ...................... 40 5.1.3 Independent Encoding Rules for Audio .................................. 41 5.1.4 Port Assignment...................................................................... 41

5.2 OPERATING RECOMMENDATIONS.................................................... 41 5.2.1 PTT transmission performance............................................... 41 5.2.2 Squelch transmission performance......................................... 41 5.2.3 Class of Service (CoS) and Quality of Service (QoS)............. 42

5.3 RTP HEADER ........................................................................................ 42 5.4 REAL-TIME TRANSPORT PROTOCOL HEADER EXTENSION (RTP-HE) 43 5.5 RTP HEADER EXTENSION FOR RADIO APPLICATIONS.................. 43

5.5.1 RTP Header Extension packet types...................................... 43 5.5.2 GRS Transceiver/transmitter PTT activation/ de-activation.... 44 5.5.3 GRS Transceiver/Receiver Squelch activation/ de-activation 47 5.5.4 RTP Header Extension description......................................... 49 5.5.5 RTPTx Information field .......................................................... 52 5.5.6 Multiple RTP audio stream management at GRS

Transceiver/Transmitter .......................................................... 54 5.5.7 RTPRx Information field.......................................................... 55

5.6 Additional Features block ....................................................................... 58 5.6.1 Serialisation of multiple Additional Feature blocks ................. 59 5.6.2 Signal Quality Information....................................................... 59 5.6.3 CLIMAX-Time Delay ............................................................... 61 5.6.4 Radio Remote Control ............................................................ 62 5.6.5 Dynamic Delay Compensation................................................ 67

CHAPTER 6 REAL TIME SESSION SUPERVISION ................................................................. 70 6.1 INTRODUCTION.................................................................................... 70 6.2 R2S RADIO SIGNALLING MESSAGE TYPES...................................... 70 6.3 R2S SDP ATTRIBUTES......................................................................... 71 6.4 R2S OPERATION .................................................................................. 72 6.5 RTP HEADER STRUCTURE FOR R2S-KEEPALIVE PACKETS ......... 72

ANNEX A REFERENCES ...................................................................................................... 74 ANNEX B BEST SIGNAL SELECTION AND AUDIO LEVEL QUALITY INDEX RECEPTION 76

B.1. OBJECTIVES OF THIS ANNEX ............................................................ 76 B.2. BSS DEFINITION................................................................................... 76

B.2.1. Parameters.............................................................................. 76 B.3. ARCHITECTURES................................................................................. 78

© EUROCAE, 2012

iv

B.4. QUALITY INDEX CODING..................................................................... 80 B.4.1. Parameters coding.................................................................. 80 B.4.1.1. Classes ................................................................................... 81

B.5. CONCLUSION........................................................................................ 82 ANNEX C CLIMAX CONSIDERATIONS................................................................................ 83

C.1. PURPOSES............................................................................................ 83 C.2. PRINCIPLE............................................................................................. 83 C.3. ISSUES RAISED.................................................................................... 83 C.4. ECHO EFFECTS.................................................................................... 83 C.5. SIGNAL FADING.................................................................................... 84 C.6. IMPLEMENTATION PRECAUTIONS .................................................... 84 C.7. AIR-TO-GROUND COMMUNICATIONS ............................................... 84 C.8. GROUND-TO-AIR COMMUNICATIONS ............................................... 84

ANNEX D SECURITY CONSIDERATIONS ........................................................................... 85 D.1. SIP CALL CONTROL ............................................................................. 85 D.2. VOICE PACKET SPOOFING................................................................. 85 D.3. DENIAL OF SERVICE (DOS) ATTACKS............................................... 85

ANNEX E RTP HEADER EXTENSION BIT RATE CALCULATION ...................................... 86 ANNEX F DYNAMIC DELAY COMPENSATION ................................................................... 87

F.1. FUNCTIONAL DESCRIPTION OF THE METHOD................................ 87 F.1.1. Preconditions for a Reliable Operation ................................... 87 F.1.2. Format of Time Values............................................................ 87 F.1.3. Quality of Time Values............................................................ 87

F.2. ONE WAY AUDIO DELAY ESTIMATION .............................................. 88 F.2.1. Absolute time available ........................................................... 90 F.2.2. Relative time available ............................................................ 90

ANNEX G ACRONYMS .......................................................................................................... 91 ANNEX H LIST OF EUROCAE WG-67 SG1 CONTRIBUTORS (in alphabetical order)........ 94

© EUROCAE, 2012

v

REQUIREMENTS TABLE

COMMUNICATION MODEL 1 [COMMUNICATION MODEL] Scope of the specifications ................................................................ 8 2 [COMMUNICATION MODEL] Applicable configurations ................................................................... 8 3 [COMMUNICATION MODEL] Applicable Protocol ............................................................................ 9 4 [COMMUNICATION MODEL] Concurrent communications between VCS and GRS ....................... 9 5 [COMMUNICATION MODEL] Communication initiation between VCS and combined GRS .......... 10 6 [COMMUNICATION MODEL] Communication initiation between VCS and separate GRS Tx and

GRS Rx .................................................................................................................................. 11

SESSION IINITIATION PROTOCOL (SIP) 1 [SIP] SIP Version............................................................................................................................. 13 2 [SIP] SIP Supported requests .......................................................................................................... 13 3 [SIP] SIP Supported response ......................................................................................................... 16 4 [SIP] SIP Message body (SDP)........................................................................................................ 23 5 [SIP] SIP Address Format ................................................................................................................ 31 6 [SIP] Basic call functionalities........................................................................................................... 31 7 [SIP] Normal SIP session establishment.......................................................................................... 31 8 [SIP] Emergency SIP session establishment ................................................................................... 32 9 [SIP] SIP Audible Tones control ....................................................................................................... 34 10 [SIP] SIP Call Set Up procedure .................................................................................................... 34

AUDIO

1 [AUDIO] Audio level specifications................................................................................................... 38 2 [AUDIO] Voice quality....................................................................................................................... 38 3 [AUDIO] Voice latency time performance......................................................................................... 38 4 [AUDIO] Voice Packetization interval requirement........................................................................... 38 5 [AUDIO] Voice coding requirement .................................................................................................. 39

REAL TIME TRANSPORT PROTOCOL (RTP)

1 [RTP] RTP Audio and Radio Signalling protocol requirement......................................................... 40 2 [RTP] RTP Profile specific items requirement .................................................................................. 40 3 [RTP] RTP Encoding Rules.............................................................................................................. 41 4 [RTP] RTP and RTCP UDP Port number......................................................................................... 41 5 [RTP] RTP PTT transmission performance...................................................................................... 41 6 [RTP] RTP A/C Call transmission performance .............................................................................. 41 7 [RTP] RTP Class of Service ............................................................................................................. 42 8 [RTP] RTP Header specifications.................................................................................................... 42 9 [RTP] RTP Radio PTT activation/de activation ................................................................................ 44 10 [RTP] RTP Radio A/C Call activation/de activation......................................................................... 47 11 [RTP] RTP Header Extension description ....................................................................................... 49 12 [RTP] RTPTx Information field ........................................................................................................ 52 13 [RTP] RTPRx Information field ........................................................................................................ 55 14 [RTP] RTP BSS quality index method- RSSI .................................................................................. 61 15 [RTP] RTP Climax operation timing ................................................................................................ 61 16 [RTP] Keepalive messages ............................................................................................................. 72

© EUROCAE, 2012

vi

FIGURE INDEX Figure 1: Vienna Agreement ................................................................................................................... 2 Figure 2: SIP connection between VCS and Single Tx/Rx Radio......................................................... 10 Figure 3: SIP session between VCS and separated Rx and Tx radios................................................. 12 Figure 4: Example of successful SIP session establishment between VCS endpoint and GRS

Transceiver endpoint.............................................................................................................. 35 Figure 5: RTP header (RFC 3550 p.12) ................................................................................................ 42 Figure 6: RTP Packets types................................................................................................................. 43 Figure 7: Transmission Timing Diagram ............................................................................................... 45 Figure 8: Signalling Status operating mode .......................................................................................... 46 Figure 9: Reception Timing Diagram..................................................................................................... 48 Figure 10: RTP header extension ......................................................................................................... 50 Figure 11: Basic Radio System topology .............................................................................................. 51 Figure 12: RTPTx Information field ....................................................................................................... 52 Figure 13: Partitioning of the Extension for additional features ............................................................ 54 Figure 14: RTPRx Information field ....................................................................................................... 55 Figure 15: PTT Confirmation for separated GRS (A) and Combined GRS (B)..................................... 57 Figure 16: SQI TLV Coding ................................................................................................................... 60 Figure 17: CLIMAX Time Delay TLV Coding......................................................................................... 62 Figure 18: RRC RTPTx TLV Coding .............................................................................................. 63 Figure 19: “Paired Frequency” RRC RTPRx TLV Coding..................................................................... 64 Figure 20: “Single Frequency” RRC RTPRx TLV Coding ..................................................................... 66 Figure 19: RTP-Audio and R2S-Keep Alive packets............................................................................. 71 Figure 20: AGC Voltage Law................................................................................................................. 77 Figure 23: Simple Radio-VCS connection............................................................................................. 78 Figure 24: Climax Configuration; voter not included within VCS........................................................... 79 Figure 25: Climax configuration; voter embedded within VCS.............................................................. 80 Figure 27: Voice Delay: CWP – Antenna ............................................................................................. 88 Figure 28: Message Flow Example for one-way delay estimation........................................................ 90

TABLE INDEX Table 1 – Supported SIP Requests....................................................................................................... 13 Table 2 – Supported SIP Responses .................................................................................................... 17 Table 3 – SIP UA Request Header Fields............................................................................................. 20 Table 4 – Mapping between Requests and UA Response Header Fields............................................ 22 Table 5 – Priority Header Field Values.................................................................................................. 22 Table 6 – Subject Header field values................................................................................................... 22 Table 7 – Supported SDP Types and Parameters................................................................................ 25 Table 8 – Supported SIP Responses .................................................................................................... 36 Table 9 – Supported Reason Header values ........................................................................................ 37 Table 10 – Properties of Audio Codecs (RFC 3551 p.10, p.28)............................................................ 39 Table 11 – Profile Specification of RFC 3550 ....................................................................................... 41 Table 12 – PTT Value List ..................................................................................................................... 52 Table 13 – Squelch Information bit........................................................................................................ 56 Table 14 – RTPTX Additional Feature Type definition.......................................................................... 59 Table 15 – RTPRX Additional Feature Type definition ......................................................................... 59 Table 16 – TLV Values for SQI ............................................................................................................. 60 Table 17 – Definition of Quality Index Values ....................................................................................... 60 Table 18 – List of BSS Quality Index Methods...................................................................................... 61 Table 19 – TLV Values for CLIMAX Time Delay................................................................................... 61 Table 20 – TLV Values for RMM for RTPTx direction........................................................................... 68

© EUROCAE, 2012

© EUROCAE, 2012

vii

Table 21 – TLV Values for RMM for RTPTx direction........................................................................... 69 Table 22 – BSS Parameters.................................................................................................................. 81 Table 23 – Level Partitioning................................................................................................................. 81 Table 24 – S-Meters for VHF/UHF........................................................................................................ 82 Table 25 – Bit Rate Calculation for 3 different RTP Packet types......................................................... 86

1

CHAPTER 1

INTRODUCTION

1.1 BACKGROUND

Ground-Ground (G-G) ATM voice systems have been based upon analogue and more recently, digital Time Division Multiplexing / Pulsed Code Modulation (TDM/PCM) technologies for many years. Nowadays, however, convergence of voice and data into one multimedia network is a popular trend with a variety of technical solutions available on the market. Following in this direction ATM communication networks are adopting, by a process of gradual evolution, a common infrastructure for voice and data services. As the technology has developed IP Technology has now the true potential to fulfil operational and technical ATM communication requirements - including those of voice / data convergence, Quality of Services (QoS), security and safety. There is also the possibility that IP may deliver solutions that will, over time, bring about true savings in investment and operating costs. EUROCAE Working Group 67 (WG-67) undertook the mission to assess the feasibility of using Voice over Internet Protocol (VoIP) for providing ATM voice services. The group defined criteria, requirements and guidelines based upon the following operational needs and constraints: • Operational and Technical Air-Ground (A-G) and Ground-Ground (G-G) ATM

Voice system requirements; • Existing IP Voice protocols and signalling standards; • IP network capabilities for Voice services; • Security, Quality of Service (QoS), and Convergence (infrastructure, protocol,

applications); • Existing IP Voice ATM system capabilities and service interfaces. The following tasks were identified to fulfil the WG-67 mission: • Define ATM Systems and identify their components (Voice Communication

System / VCS, Ground-based Radio Station / GRS) • Determine possible additional operational and technical ATM requirements for

new ATM voice systems, also taking into consideration A-G communications. • Make recommendations to upgrade current standardisation documents. • Develop a Technical Specification for a VoIP Voice ATM System including:

o Minimum performance and safety/security requirements for the system and, if appropriate, for components;

o Interoperability requirements between IP components of the VoIP ATM system;

o Minimum performance requirements of an IP Network to support ATM Voice services;

Consequently the following three documents were delivered: ED-136 - VoIP ATM System Operational and Technical Requirements ED-137 - Interoperability Standards for VoIP ATM Components ED-138 - Network Requirements and Performances for VoIP ATM Systems

© EUROCAE, 2011

2

The contents of all three documents are premised on the “Vienna Agreement” which defines the different components of a VoIP ATM system and their mutual interfaces as depicted in . Figure 1

FIGURE 1: VIENNA AGREEMENT

VoIP components are interconnected through an IP network and suppliers are free to define their internal architecture (IP/Ethernet, TDM/PCM - Time Division Multiplexing/Pulsed Code Modulation, etc.) Between VoIP components, required interfaces are defined to guarantee their functional and technical interoperability. Therefore, VoIP ATM Systems are composed of: • VoIP VCS Components performing Radio and / or Telephone functions,

including: 1. Controller Working Positions, assuring HMI including voice devices

(microphone and loudspeaker); 2. Possible local VCS Maintenance and Configuration stations; 3. Possible local Recording devices; 4. Possible LAN for local interconnection; 5. Possible Media Gateways to legacy systems (ATS-QSIG, ATS-R2, ATS-

No.5, PSTN, Radio analogue lines, etc.) • VoIP Ground Radio Station Components performing DSB-AM VHF and UHF

Radio functions. • VoIP Supervision System Components performing monitoring and control

functions. • VoIP Recording Components performing recording functions. • IP WAN Components performing interconnection services between two or

more different physical components.

© EUROCAE, 2012

3

1.2 ED-137 VOLUME 1 PRESENTATION

The scope of the WG67 ED-137 Documents is to define the rules for VoIP implementations to support ATM communications: • Radio for the Volume 1 • Telephone for the Volume 2 • European Legacy Telephone Interworking for the Volume 3 • Recording for the Volume 4 • Supervision for the Volume 5 This includes the performances requested for the related communications. The present document, that is the ED-137 Volume 1, proposes a profile standard for the use of SIP to establish, terminate and modify speech media sessions of the Ground Radio communication service in an Air Traffic Services Ground Voice Network (AGVN). Current Ground-to-Ground (G-G) Air Traffic Management (ATM) voice communication systems (VCS) are based on a hybrid analogue or digital technology, using point-to-point circuits, radios and disparate service infrastructures. ETHERNET and VoIP bring a revolutionary change to provide reliable, cost-effective, and scalable communications capacity to meet future ATM demands. A promising approach exists that will enable an upgrade of the aviation voice network infrastructure using Voice over Internet Protocol (VoIP) technology. The IP technology improvement is capable of supporting a broad variety of ATM applications (Radar data information, Voice communication for Radio and Telephone. This approach yields significant cost savings, enables centralized management, and provides dynamic scalability and reconfiguration of service deployments to meet the changing demands of modern ATM services. SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over the Internet Protocol (IP) (RFC 791 [3] and RFC 2460 [6]). Telephone calls are considered as a type of multimedia session where just audio is exchanged. SIP is defined in RFC 3261 [12]. This document proposes a specification for the signalling profile both for basic services, which provide a bi-directional transfer capability for speech media between user terminals in an IP AGVN employing SIP, and for call-related signalling in support of ATS supplementary services.

1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS AND OPTIONS

The terminology for requirements, recommendations and options in this document is based on RFC 2119 [6], which specify Best Current Practice regarding the use of Key Words for the Internet Community. As such, the following terminology is applied: • The word SHALL denotes a mandatory requirement; • The word SHOULD denotes a recommendation; • The word MAY denotes an option. To avoid confusion with their natural meanings in the English language, the words SHALL, SHOULD, and MAY take on the meaning stated above only where printed in boldface. When printed in normal (Arial) typeface, the natural English meaning is meant. Detailed description of terminology: 1. SHALL: This word has the same meaning as the phrase "REQUIRED" and

means that the definition is an absolute requirement of the specification. 2. SHALL NOT: This phrase means that the definition is an absolute prohibition of

the specification. 3. SHOULD: This word, or the adjective "RECOMMENDED", means that there

may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

© EUROCAE, 2012

4

4. SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

5. MAY: This word, or the adjective ”OPTIONAL“, means that an item is truly optional.

1.4 VERSION TRACKING

The present document, ED-137 Volume 1, SHALL be referenced as radio.01 in the WG67-Version SIP header field as described in 0.

© EUROCAE, 2012

5

CHAPTER 2

RADIO COMMUNICATION MODEL

2.1 DEFINITIONS

The following terms are used in this document: • A/C Call Indication: the A/C call indication is used in this document to define a

transmission from an aircraft is being received, by opposition with the Squelch indicator which is used for any kind of transmission reception (might be an aircraft transmission or the receipt of a controller transmission).

• A/C TxRx: Aircraft combined Transmitter/Receiver “Transceiver” • Aircraft Call Indication Delay (ACD): The end-to-end delay between a

transmission being received at the ground radio station antenna and the A/C call indication at the Controller Working Position (CWP)

• ARx: A timing parameter associated with a signal received by an aircraft • ATx: A timing parameter associated with a signal transmitted from an aircraft • Best Signal Selection Input Delay Differential (BIDD): the comparative time

difference between two received signals as inputs to a VCS BSS Device. • BIDD Max: The maximum value of BIDD as specified by the VCS supplier • BIDD Variation/Jitter: The range by which BIDD MAY vary over time. • Best Signal Selection (BSS) Delay: The time taken for BSS to be completed. • Best Signal Selection (BSS): A process by which a particular radio audio

signal is selected “as best” for presentation to the User - and retransmission if cross-coupling is selected.

• Call Established: A call established condition exists when a one-way voice channel (i.e. in half-duplex radio operation) is fully available for use between two Users.

• Call Establishment Delay (CED): The total time taken between the Push-To-Talk (PTT) action by a User and the time for the squelch to operate in the called party’s receiver. After this time a Call Established condition exists. This is assumed to be equivalent to the FAA term “Voice Channel Set-up delay” below

• Called Party: The User who receives the transmission from the Calling Party. • Calling Party: The User who initiates a transmission by means of their Push-

To-Talk (PTT) key. • Controller Working Position (CWP): Contains all the HMI components (i.e.

radio, telephone and radar facilities etc) as MAY be required by an individual User in carrying out their operational duties (See also “Sector Suite”).

• Endpoint: is a logical instance responsible with transmission and/or reception of a media stream

• ECMA: An international industry association dedicated to the standardisation of information and communication systems.

• Ground Radio Station (GRS): used to indicate all equipment at a radio site. (E.g. Radio Transceiver, Radio Transmitter, Radio Receiver, or Radio Remote Control Equipment).

• GRS endpoint: is GRS equipment hosting the SIP signalling entity (SIP UAS) and the audio processing entity (RTP) that handles the VOIP communication with the VCS endpoint. The GRS endpoint could be, e.g., a VOIP radio or a VOIP gateway. Thus, a GRS Transmitter endpoint is, e.g., a VOIP transmitter or a VOIP radio gateway which connects to an analogue transmitter.

• GRx: A timing parameter associated with a signal received on the ground.

© EUROCAE, 2012

6

• GTx: A timing parameter associated with a signal to be transmitted from the ground.

• Paired Frequency Configuration: In the paired frequency configuration the RRCE is connected to the following radio complement:

• Main F1 Transmitter (MTxF1) and Standby F1 Transmitter (STxF1) • Main F1 Receiver (MRxF1) and Standby F1 Receiver (SRxF1) • Main F2 Transmitter (MTxF2) and Standby F2 Transmitter (STxF2) • Main F2 Receiver (MRxF2) and Standby F2 Receiver (SRxF2) NOTE 1: A remote radio site may be implemented with all the radios or just a subset

of it. NOTE 2: A remote radio site may be implemented with any combination of Legacy

analog radios or VoIP radios connected to the RRCE. They are treated identically from a protocol perspective.

• PTT - Push To Talk: The physical action taken by the User in operating their

transmit key. The term “Key” is used to denote any type of device including buttons, levers, foot switches, computer mouse and LCD/Plasma panel segments etc.

• PTT- A/C Call Round-Trip Delay: The total time taken between a User operating their Push-To-Talk (PTT) key and when an A/C Call indication appears on their CWP.

• PTT Delay (PTTD): This is the delay arising from the need to operate a transmitter remotely and would be nil if the User was actually physically located in the same place as the transmitter.

• PTT Key: Push to Talk Key – a physical device for carrying out a Push-To-Talk (PTT) action.

• Radio Control Equipment (RCE): used to control radio transmitters and receivers remotely on the ground.

• Radio Control Equipment – Local (RCE-L): RCE in the locality of the controller.

• Radio Control Equipment - Remote (RCE-R): RCE remote from the controller (i.e. located at the radio station).

• Receiver Activation Time (RAT): The total time taken for a receiver to have detected the presence of a radio signal of desired minimum quality, causing both the Automatic Gain Control (AGC) proceeded by the squelch mechanism to operate. After this time period the audio channel is fully available within the receiver to present any de-modulated audio at the receiver audio output.

• Receiver De-activation Time (RDAT): The total time taken for a receiver to have detected the absence of a radio signal that had previously caused Receiver Activation resulting in inhibition of the Automatic Gain Control (AGC) and de-activation of the squelch mechanism. After this time period the audio channel is silent with no audio at the receiver audio output.

• R2S: Real Time Session Supervision Protocol: Used to monitor the status of the network links between the VCS and the Radios

• RRC Command Message: RRC command messages are always issued by a VCS endpoint. An RRC command message is an RTP Voice or R2S- Keepalive Packet containing a Radio Remote Control Additional Feature Type sent from a VCS endpoint.

• RRC Response Message: RRC response messages are always issued by a RRCE endpoint. An RRC response message is an RTP Voice or R2S- Keepalive Packet containing a Radio Remote Control Additional Feature Type sent from an RRCE endpoint.

© EUROCAE, 2012

7

• Remote Radio Control Equipment: The Remote Radio Control Equipment (RRCE) contains the SIP UA for the connected analog radios. The Remote Radio Control Equipment can be set either in Single Frequency or Paired Frequency configuration

• Sector Suite: A number of Controller Working Positions (CWPs) that are co-located so that a number (typically two or three) Users perform the function of managing a defined area or sector of airspace. As an example a typical Sector Suite MAY be manned by a Controller, Planner and an Assistant each with their own CWP.

• Single Frequency Configuration: In the single frequency configuration two transmitters (Main and Standby) and two receivers (Main and Standby) all tuned to a single frequency are connected to the RRCE.

• SIP: SIP is the session initiation protocol defined by RFC 3261 [12]. It defines the control messages to create and terminate communications sessions between multiple endpoints on IP networks.

• SIP Headers: SIP Headers are a set of parameters that could be assigned specific values inside a SIP message. They convey information about the SIP request or response.

• SIP Messages: SIP Messages are the basic language elements in SIP. Each SIP message contains SIP headers and may contain a message body. There are two types of SIP Messages: Request and Response.

• SIP Network Entity: A SIP Network Entity is any network component that supports SIP signalling.

• SIP Profiles: Profiles in SIP define headers to be used as well and values restrictions and definitions. It also defines which SIP Internet Draft to use and how to use them. Profiles may be defined by any organization. This document defines one of such profiles.

• SIP Request Methods: SIP Request Methods are messages, typically, sent by the SIP client to initiate a transaction. For example, an INVITE method starts a new call. A CANCEL method cancels the request.

• SIP Responses: SIP Responses are messages received by the SIP client during a transaction that was initiated by a request. One or more responses can take place in answer to a single request.

• Squelch signal: this term is used in this specification as a signal that indicates when a radio frequency input signal level to a GRS receiver is strong enough to be passed through to the desired audio path. It may be either an aircraft transmission or the receipt of a VCS transmission from the associated GRS transmitter

• Squelch Delay (SqD): The delay arising from the need to operate the squelch output device at a location remote from the receiver (usually a Controller Working Position – if installed) and would be nil if the User was actually physically located in the same place as the receiver.

• System: implies entire VCS, Controller Working Positions, IP WAN and all related internal and external interfaces.

• Transmitter Activation Delay Differential (TADD): the comparative difference in time taken for two transmitters to be activated when keyed from a common point.

• Transmitter Activation Delay Differential (TADD) Max: The maximum value of TADD to ensure satisfactory Multi-carrier/Climax operation.

• Transmitter Activation Delay Differential (TADD) Variation / Jitter: The range by which TADD MAY vary over time.

• Transmitter Activation Delay (TAD): the total time taken between the Push-To-Talk (PTT) action by the User and the time that the transmitter has attained the power level as detailed in the Transmitter Activation Time (TAT) definition.

© EUROCAE, 2012

8

• Transmitter Activation Time (TAT): the total time taken for a transmitter to have attained a nominal usable RF power output using a local Push-To-Talk (PTT). After this time the radio frequency is regarded as being in use.

• Transmitter De-activation Time (TDAT): The total time taken for a transmitter power output to have decayed to a nominal RF power output after removal of a local Push-To-Talk (PTT). After this time the radio frequency is regarded as being free for further use.

• User: an Air Traffic Controller or other operational person carrying out the duties of Air Traffic Management.

• User Agent Client: A User Agent Client (UAC) is the logical entity within each network component that creates new requests.

• User Agent Server: A User Agent Server (UAS) is the logical entity within each network component that generates a response to a SIP request.

• Voice Communication System (VCS) or Voice Communication Control System (VCCS): the main equipment providing radio (and telephone) facilities to the Controller Working Position.

• VAD: Voice Activity Detection • Voice Delay: the one-way User-to-User voice delay between analogue system

interfaces (Example: Controller microphone to Pilot Earphone) once the call is established.

• X-Couple (Cross-Coupling 2 or more radio frequencies): frequency cross-coupling is a CWP selected function causing automatic retransmission of one received signal on other pre-selected radio frequencies. With Cross-Coupling it is possible to merge a number of physical radio frequencies into a kind of logical frequency.

2.2 PROTOCOL STACK

1 [COMMUNICATION MODEL] Scope of the specification The scope of this specification is to define the Audio, Signalling and Management interworking between a User Agent at a Voice Communication System (VCS) endpoint and a SIP User Agent at a Ground Radio Station (GRS) endpoint connected through an IP network. 2 [COMMUNICATION MODEL] Applicable configurations This specification defines the interworking between User Agents at VCS and GRS endpoints for the following configurations: • Combined GRS: Radio Transceiver or Transmitter and Receiver located at the

same site and accessible from the IP network by one application address (SIP URI);

• Separated GRS: Radio Transmitter and Radio Receiver located at different sites or at the same site but accessible from the IP network by different application addresses (SIP URI);

2.3 BASIC PROTOCOL REQUIREMENTS

In order to initially establish a communication path between a User Agent at a VCS endpoint and a User Agent at a GRS endpoint and to transport both audio, keep-alive and radio signalling between these endpoints, the interfaces SHALL be capable of employing the following protocols in order to achieve the required functionality: • the SIP protocol employed to initially establish a SIP session between the User

Agents at the VCS and GRS endpoints; • R2S protocol allowing the monitoring of the link between VCS and Radios when

no voice is exchanged

© EUROCAE, 2012

9

• RTP protocol used to open a two-way RTP communication between the User Agents and then to transport audio packets (when PTT or Squelch is activated) and Keepalive packets (when PTT or Squelch is deactivated). Each RTP packet header sent with RTP Audio packets and R2S-Keepalive packets SHALL include an RTP Header Extension (HE) used to transport the Radio Signalling to and from the GRS endpoint.

3 [COMMUNICATION MODEL] Applicable Protocols The SIP, RTP and R2S protocol SHALL be the minimum requirements necessary for the implementation in order to provide VoIP communication between the User Agents at the VCS and GRS endpoints. The RTP protocol SHOULD be augmented by its associated control protocol (RTCP) to allow monitoring of the audio packets delivery. 4 [COMMUNICATION MODEL] Concurrent communications between VCS and GRS A VCS SHALL be able to establish more than one SIP session with a GRS. A GRS SHALL be able to accept SIP session establishment from different User Agents each with a different SIP URI. These User Agents could be located at the same VCS site or dispersed between several different VCS sites. A GRS SHALL be configured in order to accept SIP session establishments with one or multiple VCS. A GRS SHALL be able to independently process up to the configured maximum number of RTP communications associated with those established SIP sessions. A GRS SHALL be able to operate at least two concurrent SIP sessions.

2.4 MODES OF OPERATION

2.4.1 Real time Transport Protocol (RTP) and Real time Transport Header Extension

The Real time Transport Protocol SHALL be used to transport audio data and real time radio signalling information between User Agents at the VCS and GRS endpoints. The Real time Transport Protocol Header Extension (RTP-HE) SHALL be employed to transport, among others, the following signalling information: a) PTT (Push To Talk) b) PTT-ID identifies the transmitting device c) Squelch (SQL); d) Quality index (used for the Best Signal Signalling feature) e) Relative Time Delay Information (used for CLIMAX application) f) PTT mute flag g) Simultaneous transmission indication h) Reserved field for proprietary applications i) Keep alive information On the Transmit path when PTT is deactivated at the VCS endpoint, there is therefore no audio to be transmitted and the Real time Transport Protocol SHOULD NOT transport audio data towards the GRS endpoint. On the Receive path when there is no Aircraft Call detected at the GRS, the squelch signal is deactivated at the GRS endpoint and there is therefore no audio to be sent towards the VCS endpoint. The Real time Transport Protocol SHOULD NOT transport audio data towards the VCS endpoint. When no audio has to be exchanged, the R2S protocol SHALL be employed for radio signalling exchange only.

© EUROCAE, 2012

10

2.4.2 Combined GRS configuration

5 [COMMUNICATION MODEL] Communication initiation between VCS and combined GRS In the case that a GRS Transceiver or a GRS Transmitter/Receiver located at the same site and accessible by one SIP URI, the communication between the VCS endpoint and a GRS endpoint SHALL be performed in two distinct phases • Phase 1: o The SIP session SHALL always be initiated from the VCS endpoint towards the

GRS endpoint (transceiver, transmitter or receiver). o The SIP protocol SHALL be used to initiate the connection between VCS and

GRS endpoints and to define/negotiate the parameters to be used during the session through the Session Description Protocol (SDP). These include parameters for a two-way RTP communication to be established.

• Phase 2: o Once the SIP session is established, both VCS and GRS endpoints SHALL use

the “Keep Alive” mechanism of the R2S protocol to control the link between the VCS and the GRS. R2S-Keepalive packets will always be exchanged between endpoints in the case that no audio is present.

o When PTT or Squelch signals are activated the RTP packets SHALL be used to transport audio data between the endpoints.

o Both RTP Audio and R2S-Keepalive Packets SHALL always contain the RTP header extension used for the real time transportation of Radio signalling between the endpoints, i.e. PTT signal, Climax Delay from VCS to GRS endpoints, while Squelch signal, Signal Quality Information and Stepped-on transmissions signal from GRS to VCS endpoints.

FIGURE 2: SIP CONNECTION BETWEEN VCS AND SINGLE TX/RX RADIO

© EUROCAE, 2012

11

2.4.3 Separated GRS configuration

6 [COMMUNICATION MODEL] Communication initiation between VCS and separate GRS Tx and GRS Rx In the case that a GRS Transmitter and GRS Receiver are accessible by different SIP URIs, the communication between the VCS endpoint and the GRS Transmitter/Receiver endpoints SHALL be performed in two distinct phases SIP protocol SHALL be used to initiate separate communications between the VCS and GRS Transmitter/GRS Receiver equipment. Each connection will be performed in two phases: • Phase 1:

o Separate requests for SIP session establishment SHALL always be initiated from the VCS endpoint towards the GRS Receiver endpoint and/or the GRS Transmitter endpoint respectively. It SHALL be possible to establish a SIP session to a GRS Receiver only or a GRS Transmitter only.

o The SIP protocol SHALL be used to initiate the connection between VCS and both GRS Receiver and/or GRS Transmitter endpoints and to define/negotiate the parameters to be used during the session through the Session Description Protocol (SDP). These include parameters for separate two-way RTP communication to be established to both the GRS Receiver and/or the GRS Transmitter.

• Phase 2: o Once a two-way SIP session is established with the GRS Receiver and/or

the GRS Transmitter endpoint, both the VCS endpoint and GRS endpoints SHALL initiate procedures using the Real time Transport Protocol (RTP) to make a R2S connection. This has the task of controlling that the connection between the VCS endpoint and the GRS Receiver and/or GRS Transmitter endpoints are present through a periodic exchange of R2S-Keepalive packets. R2S-Keepalive packets will always be exchanged between endpoints in the case that no audio is present.

o When PTT or Squelch signals are activated the RTP packets SHALL be used to transport audio between the endpoints.

o Both RTP and R2S-Keepalive Packets SHALL always contain the RTP header extension used for the real time transportation of Radio signalling between the endpoints (i.e. PTT signal, Climax Delay from VCS to GRS Transmitter endpoints, while A/C Call signal, Signal Quality Information for BSS and Stepped-on transmissions signal from GRS Receiver to VCS endpoints).

o In order to distinguish between a Squelch Signal detected by a GRS Receiver endpoint as a result of an Aircraft call or as a result of PTT activation by a User Agent towards a GRS Transmitter endpoint, it is also necessary to inform the GRS Receiver endpoint each time PTT is activated towards a GRS Transmitter endpoint.

o When PTT is activated by a SIP User Agent this SHALL cause ptt-type and ptt-id to be sent towards the GRS Transmitter, but SHALL also cause the same ptt-type and the corresponding ptt-id to be sent towards the GRS Receiver. In this way, a GRS Receiver detecting a squelch signal and simultaneously receiving a ptt-type + ptt-id from a User Agent will recognise that the squelch signal is in fact an off-air squelch. Ptt-id SHALL also be echoed back to the VCS if PTT is off, i.e. not activated.

© EUROCAE, 2012

12

Phase 1 Phase 2

FIGURE 3: SIP SESSION BETWEEN VCS AND SEPARATED RX AND TX RADIOS

© EUROCAE, 2012

13

CHAPTER 3

PROFILE STANDARD FOR THE USE OF SIP IN AN AGVN

3.1 SESSION INITIATION PROTOCOL

1 [SIP] SIP Version An Air Traffic Services VoIP Communications System SHALL support SIP version 2 as specified in RFC 3261 [12]. The SIP protocol, is an application-layer control protocol which has been developed and designed within the IETF and is defined by RFC 3261 [12]. With respect to Ground Radio applications the SIP protocol SHALL be used by a Voice Communication System (VCS) endpoint to establish, modify and terminate a SIP session with a Ground Radio Station (GRS) endpoint within an Air Traffic Services Ground Voice Network (AGVN). Once a communication session between VCS and GRS endpoints has been established using the SIP protocol, the two endpoints SHALL then employ the Real time Transport Protocol (RTP) (RFC 3550 [21]) and its RTP Header Extension to establish a Real Time Session Supervision (R2S) communication between the endpoints. Once the Real Time Session Supervision is active between the endpoints, the same RTP communication SHALL then be used for the transport of Audio in RTP packets between the endpoints (as defined in RFC 3550 [21]), Radio signalling contained in the RTP Header Extension between the endpoints (as defined in chapter 0) and the transport of R2S-Keepalive packets between the endpoints when there is no Audio to be transported (as defined in 0). The audio transport MAY be augmented by its associated control protocol (RTCP) (RFC 3550 [21]) to allow monitoring of voice packet delivery.

3.2 LOGICAL ATS-SIP ENTITIES

The logical ATS SIP Entities like, User Agent, Registrar and Proxy Server are described in the EUROCAE ED-137 Part 2 – Telephone document [37]. For the Ground Radio Service within the IP AGVN the SIP Entities Registrar and Proxy Server are OPTIONAL. All User Agent services regarding Registration are also OPTIONAL.

3.3 SUPPORTED REQUESTS

2 [SIP] SIP Supported requests The following requests methods SHALL be supported for both UACs and UASs in a VCS and a radio that support SIP:

User Agent VCS User Agent GRS Method Sending Receiving Sending Receiving

INVITE m x x m ACK m x x m CANCEL m x x m BYE m m m m REGISTER o - o - INFO o o o o SUBSCRIBE m o o m NOTIFY o m m o UPDATE m m x o OPTIONS o o o o REFER o m - o MESSAGE o m - o PUBLISH o o o o PRACK o o o o

“m”: mandatory; “o”: optional; “x”: prohibited; “-“: not applicable

TABLE 1 – SUPPORTED SIP REQUESTS

© EUROCAE, 2012

14

The requirements of RFC 3261 [12], RFC 3262 [13] , RFC 3265 [15], RFC 3311 [16] and RFC 3515 [20] SHALL apply with modifications as specified in the following sub-clauses.

3.3.1 INVITE and RE-INVITE

The INVITE request message SHALL always be sent by the User Agent at the VCS endpoint towards the User Agent at the GRS endpoint and is used to request SIP session establishment to the GRS endpoint. The INVITE request SHALL include an SDP body defining media information of the VCS endpoint. Once a session has been established, it is possible for the User Agent at the VCS endpoint to modify SDP parameters etc (i.e. codec, call types, etc.) and RTP receiving address ports though the use of a new INVITE request message within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a Re-INVITE request message.

3.3.2 ACK

INVITE requests SHALL include an SDP body for all type of calls; nevertheless, UAS SHOULD support receiving INVITE requests with no SDP body.” – ACK with SDP is not recommended. An ACK request message SHALL be sent by the User Agent at the VCS endpoint and SHALL only contain an SDP message body if this was not contained in the initial INVITE message.

3.3.3 CANCEL

The CANCEL request message SHALL be sent by the User Agent at the VCS endpoint to cancel a previously sent INVITE request. It can only be sent if a final 200 OK response has not been sent from the User Agent at the GRS endpoint. A CANCEL request received by the User Agent at the GRS endpoint instructs the User Agent to cease processing the INVITE request and to generate an error response to that request (i.e. error response code: 487). CANCEL has no effect on a request to which a UAS has already given a final response.

3.3.4 BYE

The BYE request message SHALL be sent by the User Agent at the VCS endpoint to terminate an established SIP session with the User Agent at the GRS endpoint (i.e. a final 200 OK response has been received by the User Agent at VCS endpoint). A BYE request message SHALL NOT be sent by a User Agent at an endpoint if a SIP session hasn’t been established. The BYE request message SHALL be sent by the User Agent at the GRS endpoint to terminate an established SIP session with the User Agent at the VCS endpoint only in the following cases: • The GRS endpoint has received an INVITE request message from a User

Agent at another VCS endpoint that contains a SIP Priority Header Field defined as “emergency” and the GRS endpoint has insufficient resources to establish the SIP session due to the maximum number of simultaneous SIP sessions configured at the GRS endpoint already being reached.

• When the R2S timer “R2S-LocalHoldTime” reaches zero (see chapter 0). • The GRS endpoint changes to the maintenance mode (local mode) and isn’t

thus anymore in operation. • An internal radio error occurs, which prevents normal operation. • The frequency of the GRS receiver/transmitter/transceiver was changed. (e.g.

by a management or an operational control session) • (optional) The GRS endpoint has received an INVITE request message from a

User Agent at another VCS endpoint that contains a SIP attribute linked session with the parameter: “DeleteLS”

© EUROCAE, 2012

15

NOTE: In the case that the frequency is changed by a radio remote control session, all other sessions shall be terminated, but not the session which belongs to the radio remote session.

3.3.5 REGISTER

The REGISTER request message MAY be sent by the User Agent at the VCS or GRS endpoints to a REGISTRAR server in order to notify the SIP network of its Normal and Current contact addresses. A registrar server acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER request messages. This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. As all SIP session requests are initiated from the User Agent at the VCS endpoint there is only a need to employ the location service towards GRS endpoints and it will not therefore be used towards VCS endpoints. Typical use of the REGISTRAR server will therefore be used to ensure GRS endpoints are present on the SIP network and also to enable SIP session establishment requests to be routed to a different User Agent at a GRS endpoint (e.g. Switch-over from Main to Stand-by Radio). If a registration between a SIP UA and a SIP server (SIP proxy, SIP registrar) is accomplished, the (authentication) process SHALL be made in accordance with section 10 of RFC 3261 [12], and section 2 of RFC 3265 [15] SUPPORTED RESPONSES.

3.3.6 WG67 KEY-IN Event Package

This event package SHALL be used to inform any User Agent in the network that has subscribed to the WG67 KEY-IN service about the current bindings that exist between all User Agent URI addresses at the various VCS endpoints that currently have SIP sessions established to the GRS Receiver, Transceiver or Transmitter endpoint (i.e. have the capability to activate PTT towards the GRS transmitter) and the individual ptt-id that was assigned by the GRS Receiver, Transceiver or Transmitter endpoint to each of these User Agents. The event package SHOULD also inform about the radio access mode (SDP attribute <call type>) of each established SIP session. The binding information SHALL be transmitted as a comma separated text string, with each pair separated using carriage return and line feed (crlf) within a NOTIFY message body defined as follows: <ptt-id-1, decimal value>, <sip-from-uri-1, sipuri format>, <call type>crlf <ptt-id-2, decimal value>, <sip-from-uri-1, sipuri format>, <call type>crlf <ptt-id-3, decimal value>, <sip-from-uri-2, sipuri format>, <call type>crlf <ptt-id-n, decimal value>, <sip-from-uri-n, sipuri format>, <call type>crlf • <ptt-id-x> SHALL be a decimal value of the assigned PTT-Id received in 200

OK. • <sip-from-uri-x> SHALL be a string with the URI of the User Agent. • <call type> SHALL have one or more of the following values (as specified in

chapter 3.6.1.4: o coupling o Radio-Rxonly o Radio-TxRx o Radio-Idle

The <call type> parameter is OPTIONAL. Example: 1,sip:user_a@domain,coupling 2,sip:user_b@domain,Radio-TxRx 3,sip.user_c@domain SIP specific event notification mechanisms ( [15]) SHALL be used to distribute this data.

© EUROCAE, 2012

16

3.3.6.1 SUBSCRIBE

The SUBSCRIBE method is used to request current state and state updates from a remote node. The Request URI of a SUBSCRIBE request, contains enough information to route the request to the appropriate entity (e.g. radio or radio gateway equipment). It SHALL include exactly one "Event" header indicating the event being subscribed. The "Event" header SHALL contain the token “WG67KEY-IN” which is indicating the type of state for which a subscription is being requested. If subscription between SIP User Agents (e.g. VCS and Transceiver or Transmitter endpoints) is accomplished, the process SHALL be made in accordance with RFC 3265 [15]

3.3.6.2 NOTIFY

NOTIFY messages are sent to inform subscribers of the current state and changes in state to which the subscriber has a subscription. As in SUBSCRIBE requests, the NOTIFY "Event" header SHALL contain “WG67KEY-IN” as single event package name for which a notification is being generated. The “Content-type” header SHALL contain: text/plain. The GRS Receiver, Transceiver or Transmitter endpoint SHALL notify all subscribed User Agents whenever a User Agent at a VCS endpoint either establishes or disconnects a SIP session to the User Agent at the GRS endpoint. A complete list of bindings between ptt-id and SIP URIs SHALL be provided. (That means each time a SIP session on the radio is established, re-established or cleared shall trigger a notification, containing the list of all current bindings). If subscription between SIP UA (e.g. at VCS and GRS Transceiver/Transmitter endpoints) is made, the process SHALL be implemented according to RFC 3265 [15].

3.4 SUPPORTED RESPONSES

3 [SIP] SIP Supported response SIP user agents shall support the reception of 1xx Provisional Responses, Successful Responses 200 and 202, Redirection 302, 4xx Request Failure Responses, 5xx Server Error Responses and 6xx Global Failure Responses.

© EUROCAE, 2012

17

User Agent VCS User Agent GRS Response Sending Receiving Sending Receiving

100 – Trying - m m - 180 – Ringing - m o - 181 – Call Is Being Forwarded - m x - 182– Queued - m x - 183 – Session Progress - m o - 200 – Ok m m m m 202 – Accepted m m m m 400 – Bad Request - m m - 404 – Not Found m m m m 405 – 408, 410,413, 414 - m m - 415 – Unsupported Media Type - m m - 416 – Unsupported URI Scheme - m m - 420,421, 423l m o m 422 – Session Interval To Small m m m m 480 – Temporarily Unavailable - m m - 481 -485, 487, 489 - m o - 486 – Busy Here - m m - 488 – Not Acceptable Here m m m m 491 – Request Pending - m m - 493 – Undecipherable - m m - 501 – Request Not Supported - m m - 502 -505, 513 - m o - 603 – Decline m m m m 604, 606 o m o m

“m”: mandatory; “o”: optional; “x”: prohibited; “-“: not applicable

TABLE 2 – SUPPORTED SIP RESPONSES

The requirements of RFC 3261 [12] and RFC 3265 [15] SHALL apply with modifications as specified in the following sub-clauses.

3.4.1 1xx Provisional Responses

3.4.1.1 100 Trying

The SDP body SHALL NOT be used in the 100 Trying response; if such a message contains this field, it SHALL be ignored.

3.4.1.2 180 Ringing

This response SHOULD NOT be sent by the GRS endpoint. If sent by the User Agent at the GRS endpoint it SHOULD be ignored by the User Agent at the VCS endpoint.

3.4.1.3 181 Call Is Being Forwarded

This response SHALL NOT be used.

3.4.1.4 182 Queued

This response SHALL NOT be used.

3.4.1.5 183 Session Progress

The 183 response SHOULD NOT be used. NOTE: Usually this provisional response is used when audio has to be sent. This

response may contain an SDP body, which also includes information of the codec and audio port for early audio session. This response has an SDP body if the UAS wants to provide early media. But since radio services are typically automatically accepting an incoming call (200 OK), this feature has no benefit and therefore it should not be used.

© EUROCAE, 2012

18

3.4.2 2xx Successful Responses

Support for the following SIP responses is REQUIRED for all UAs: • 200 OK • 202 Accepted

3.4.2.1 200 OK

A 200 OK response SHALL be sent by the GRS endpoint if the request is accepted. The 200 OK response to an INVITE message SHALL contain an SDP message body in order to offer the GRS’s capabilities to the VCS. The 200 OK response to a CANCEL, BYE, SUBSCRIBE, NOTIFY message SHALL NOT contain an SDP message body. If these messages contain a SDP message body, it SHALL be ignored.

3.4.2.2 202 Accepted

The 202 Accepted response SHALL be sent when a SUBSCRIBE request has been accepted for processing, but the processing has not been completed.

3.4.3 3xx Redirection Responses

Support for 3xx Redirection Responses is OPTIONAL by all User Agents. User Agents that do not support 3xx Redirection Responses SHALL treat a 3xx response as a 4xx Request Failure response.

3.4.4 4xx Client Failure Responses

User Agents SHALL be capable of handling the following 4xx Client Failure responses. Refer to Table 2 for mandatory/optional messages. A user agent SHALL terminate a session in case of receiving a 4xx response from a UAS. • 400 Bad Request • 401 Unauthorized • 403 Forbidden • 404 Not Found • 405 Method Not Allowed • 406 Not Acceptable • 407 Proxy Authentication Required • 408 Request Timeout • 410 Gone • 413 Request Entity Too Large • 414 Request URI Too Long • 415 Unsupported Media Type • 416 Unsupported URI Scheme • 420 Bad Extension • 421 Extension Required • 423 Interval Too Brief • 480 Temporarily Unavailable • 481 Call Leg/Transaction Does Not Exist • 482 Loop Detected • 483 Too Many Hops • 484 Address Incomplete • 485 Ambiguous • 486 Busy Here • 487 Request Terminated • 488 Not Acceptable Here

© EUROCAE, 2012

19

• 489 Bad Event • 491 Request Pending • 493 Undecipherable

3.4.5 5xx Server Error Responses

User Agents SHALL be capable of handling the following 5xx Server Failure responses. Refer to Table 1 for mandatory/optional messages. A UAC SHALL terminate a session in case of receiving a 5xx response from a UAS. • 500 Server Internal Error • 501 Not Implemented • 502 Bad Gateway • 503 Service Unavailable • 504 Server Time-out • 505 Version Not Supported • 513 Message Too Large

3.4.6 6xx Global Failure Responses

User Agents SHALL be capable of handling the following 6xx Global Failure responses. Refer to Table 1 for mandatory/optional messages. A UAC SHALL terminate a session in case of receiving a 6xx response from a UAS. • 603 Decline • 604 Does Not Exist Anywhere • 606 Not Acceptable

3.5 SUPPORTED HEADER FIELDS

The requirements of RFC 3261 [12], RFC 3265 [15], RFC 3311 [16] and RFC 3515 [22] SHALL apply with modifications as specified in the following sub-clauses. As indicated in RFC 3261 [12], header field values and parameter values SHALL be case-insensitive. Table 3

Table 3Table 3

Table 3

and Table 4 compile and summarize the minimum set of header fields that SHALL be supported in requests and responses. NOTE: According to the indicated RFCs, all the mandatory header fields appear as

mandatory in the tables (Table 3 and Table 4). Besides, Content-Length, Priority and Subject header fields (indicated as optional in the RFCs) appear here as mandatory for specific requests; this is indicated by an ‘m’ in bold face type.

3.5.1 User Agent Request Headers

Request headers apply only to SIP requests. They are used to provide additional information to the Server regarding the request itself or regarding the client. SIP User Agents in an IP AGVN SHALL be capable of sending and receiving the SIP request header fields indicated in . SIP Proxy Servers in an IP AGVN SHALL be capable of receiving the SIP request header fields indicated in . Header fields not included in SHALL NOT be sent.

© EUROCAE, 2012

20

Requests UA Request

Header Field ACK BYE CAN INV MES NOT OPT REF REG SUB UPDAllow --- o --- o o o o o o o o Allow-Events (RFC 3265 [15])

o o --- o --- o o --- o o ---

Authorization o o o o o o o o o o o Call-ID m m m m m m m m m m m Contact o --- --- m --- m o m o m m Content-Length m m m m m m m o m m m Content-Type * * --- * * * * * * * * Cseq m m m m m m m m m m m Date o o o o o o o o o o o Event (RFC 3265 [15])

--- --- --- --- --- m --- --- --- m ---

Expires --- --- --- o o --- --- o o o --- From m m m m m m m m m m m In-Reply-to --- --- --- o o --- --- --- --- --- --- Join (RFC 3911 [28])

--- --- --- o --- --- --- --- --- --- ---

Max-Forwards m m m m m m m m m m m MIME-Version o o --- o --- o o o o o o Priority --- --- --- m o --- --- --- --- o --- Proxy-Authorization o o --- o o o o o o o o Proxy-Require --- o --- o o o o o o o o Record-Route o o o o --- o o o --- o o Reason --- o o --- --- --- o --- --- -- --- Refer-To (RFC 3515 [20]

--- --- --- --- --- --- --- o --- --- ---

Replaces (RFC 3891 [27])

--- --- --- o --- --- --- --- --- --- ---

Reply-to --- --- --- o o --- --- --- --- --- --- Require --- c --- c c o c c c o c Route c c c c o c c c c c c Subject --- --- --- m o --- --- --- --- --- --- Subscription-State (RFC 3265 [15])

--- --- --- --- --- m --- --- --- --- ---

Supported --- o o m* --- o o o o o o To m m m m m m m m m m m Via m m m m m m m m m m m WG67-Version m m m m m m m m m m m

c: conditional m: mandatory m*: header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header fieldo: optional ---: not applicable (i.e. header should not be

included in the request) * : required if message body is not empty

CAN: CANCEL INV: INVITE MES: MESSAGE NOT: NOTIFY OPT: OPTIONS

REF: REFER REG :REGISTER SUB :SUBSCRIBE UPD: UPDATE

TABLE 3 – SIP UA REQUEST HEADER FIELDS

© EUROCAE, 2012

21

3.5.2 User Agent Response Headers

Response header fields apply only to response (status) messages. These header fields are used to provide further information about the response that cannot be included in the status line. The inclusion of a particular header in a response is dependent on both the status code of the response and the request that led to the response. The Status Code column in Table 4

Table 4Table 4

below indicates the status code for which a given header may be included in the response. In defined cases, a given header field MAY be used with certain status codes. In other defined cases, a given header field MAY be used with all status codes. The columns that correspond to the request methods, indicate whether a given header field MAY (o) or SHALL (m) be used in a response to that particular type of request. SIP User Agents in an IP AGVN SHALL be capable of sending and receiving the SIP response header fields indicated in . SIP Proxy Servers in an IP AGVN SHALL be capable of receiving the SIP response header fields indicated in .

Requests UA Response Header Field

Status Code ACK BYE CAN INV MES NOT OPT REF REG SUB UPD

Allow 2xx --- o --- m o o m* --- o o o Allow 405 --- m --- m m m m* m m m m Allow All

except 2xx,415

--- o --- o o o o o o o o

Allow-Events (RFC 3265 [15])

2xx o o --- o --- o o --- o o ---


489 --- --- --- --- --- m --- --- --- m ---

Authentication-Info

2xx --- o --- o o o o o o o o

Call-ID All m m m m m m m m m m m Contact 1xx --- --- --- o --- o --- --- --- o o Contact 2xx --- --- --- m --- o o m o m m Contact 3xx --- o --- o o m o --- o m o Contact 485 --- o --- o o o o o o o o Content-Length All m m m m m m m o m m m Content-Type All * * --- * * * * * * * * Cseq All m m m m m m m m m m m Date All o o o o o o o o o o o Expires 2xx --- --- --- o --- --- --- --- o --- --- From All m m m m m m m m m m m MIME-Version All o o --- o --- o o o o o o Min-Expires 423 --- --- --- --- --- --- --- --- m m --- Proxy-Authenticate

407 --- m --- m m m m m m m m

Proxy-Authenticate

401 --- o o o o --- o o o --- o

Reason 3xx,4xx, 6xx

--- --- --- o --- -- o o

Record-Route 2xx,18x o o o o --- --- o o --- --- o Record-Route 401,484 --- --- --- --- --- o --- --- --- o --- Reply-To All --- --- --- o o --- --- --- --- --- --- Require All --- c --- c c o c c c o c Supported 2xx --- o o m* --- o m* o o o o To All m m m m m m m m m m m Unsupported 420 --- m --- m o o m o m o m Via All m m m m m m m m m m m Warning All --- o o o o o o o o o o WWW-Authenticate

401 --- m --- m m m m m m m m

© EUROCAE, 2012

22

Requests UA Response Status Header Field Code ACK BYE CAN INV MES NOT OPT REF REG SUB UPD

WWW-Authenticate

407 --- o --- o o --- o o o --- o

WG67-Version All m m m m m m m m o m m

c: conditional m: mandatory m*: header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: optional ---: not applicable (i.e. header should not be included in the request) * : required if message body is not empty

CAN: CANCEL INV: INVITE MES: MESSAGE NOT: NOTIFY OPT: OPTIONS

REF: REFER REG :REGISTER SUB :SUBSCRIBE

UPD: UPDATE

TABLE 4 – MAPPING BETWEEN REQUESTS AND UA RESPONSE HEADER FIELDS

3.5.2.1 Allow

The Allow header field SHALL be used to indicate at least the following methods supported by the user agent or proxy server sending the response: “INVITE, ACK, CANCEL, BYE, and REGISTER”.

3.5.2.2 Content-Type

If an SDP body is included, the Content-Type header field SHALL take the value “application/sdp”. For SIP NOTIFY messages the Content-type header MAY contain “text/plain”. The WG-67 Key-In package SHALL contain “text/plain”.

3.5.2.3 Max-Forwards

A VCS SHOULD provide a management means of configuring the acceptable (network dependent) Max-Forwards initial value. Nevertheless, it is RECOMMENDED that the initial value for the Max-Forwards header field is set to 70 as recommended in the RFC 3261 [12].

3.5.2.4 Priority

The SIP Priority header field SHALL take the values defined in Table 5. In case that the SIP Priority header field is not included in an INVITE request, the Radio call type SHALL be assumed as “radio call” (SIP Priority header field is “normal”).

Type of call SIP Priority header field Emergency radio call emergency Radio call normal

TABLE 5 – PRIORITY HEADER FIELD VALUES

3.5.2.5 Subject

The Subject header field SHALL take the value “radio” as defined in Table 6. Only the value “radio” SHALL be accepted, any other value SHALL lead to a call being rejected (e.g. with 403 Forbidden).

Type of call SIP Subject header field Radio call radio

TABLE 6 – SUBJECT HEADER FIELD VALUES

© EUROCAE, 2012

23

3.5.2.6 WG67-Version

The WG67-Version header field SHALL appear in any request and in any response, but SIP elements need to be prepared to receive messages without that header field indicating implementations based on earlier WG-67 EDs. The syntax of the header field follows the standard SIP parameter syntax as defined in RFC 3261 [11] and SHALL have the following content: WG67-Version = “WG67-Version” HCOLON version-value *(COMMA version-value) version-value = field-value *(SEMI version-params) field-value = type “.” number type = “radio” / “phone” / “legacy-eu” / “recorder” / “supervision” number = 2*DIGIT

The field-value SHALL contain the latest document version that reflects the implemented version of the corresponding ED as listed in section 0

. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. According actions MAY be specified where applicable.


Examples are: WG67-Version: radio.01 WG67-Version: radio.01; gateway=”RRC”

NOTE: Version-params may be used for future extensions and are not described further in this document.

3.6 SDP MESSAGE BODY

4 [SIP] SIP Message body (SDP) Those SIP message bodies containing a description of the session, time and media SHALL be encoded in the Session Description Protocol (SDP) (RFC 2327 [7]). The SDP types and parameters indicated in Table 7 SHALL be supported; those received SDP types and parameters not included in Table 7 SHALL be ignored. All SDP parameters are case sensitive.

Description Types Parameters Values Protocol version (“v=”) <SDP version number> • 0

<username> (Application dependent) <sess-id> (Application dependent) <sess-version> (Application dependent) <nettype> • IN <addrtype> • IP4 (in the interim)

• IP6

Origin (“o=”)

<unicast-address> (Application dependent) Session name (“s=”) <session name> (Application dependent)

<nettype> • IN <addrtype> • IP4 (in the interim)

• IP6

Session

Connection data (“c=”)

<connection-address> (Application dependent) <start-time> (Application dependent) Time Timing (“t=”) <stop-time> (Application dependent) <media> • Audio <port> (Application dependent)

Media Media descriptions (“m=”)

<proto> • RTP/AVP

© EUROCAE, 2012

24

Description Types Parameters Values <fmt> 0 (for PCM-μ )

8 (for PCM-A ) 15 (for G728 ) 18 (for G729) 123 (for R2S) (Default value in Europe=8) (Default value in North America =0) (Value 123 has to be present at all time in addition to the codec)

<send-receive mode> sendrecv

rtpmap:<payload type> <encoding name>/<clock rate>

123 R2S/8000

rtpmap:<payload type> <encoding name>/<clock rate> (optional)

0 PCMU/8000 (for PCM-μ) 8 PCMA/8000 (for PCM-A) 15 G728/8000 (for G728) 18 G729/8000 (for G729) or 0 X-PTT-PCMU/8000 8 X-PTT-PCMA/8000 15 X-PTT-G728/8000 18 X-PTT-G729/8000

ls-pl:<linked Session protection value> (optional)

-Default value: LSDeletionDisabled -LSDeletionEnabled

ls-execute:<linked Session execute value> (optional)

-Default value: KeepLS -DeleteLS

type:<call type> Radio-Idle Radio-Rxonly Radio-TxRx or Radio (default value)Coupling

txrxmode:<connection-type> (optional)

Tx Rx TxRx

bss:<BSS quality index method> (optional)

No BSS quality index method (default value) RSSI AGC C/N PSD

sigtime:<Signalling Info Time Period> (optional)

Default: 1 PTT/PTT OFF time period in multiple of the packet interval (value 1 means the Radio signalling info is sent in every RTP voice and R2S Keepalive packet)

Attributes (“a=”)

ptt_rep:<PTT OFF Repetition> (optional)

0-3 Default: 0 Number of audio packets sent with RTPTx HE indicating that PTT is OFF or RTPRx HE indicating that SQUELCH is OFF (value 0->only 1 PTT OFF or only 1 SQUELCH OFF message).

© EUROCAE, 2012

25

Description Types Parameters Values R2S-KeepAlivePeriod: <period> (See 0)

20-1000 Default: 200 Maximum time between each R2S-keep Alive packet. integer, in milliseconds

R2S-KeepAliveMultiplier:<multiplier> (See 0)

2-50 Default: 10 Number of Keep Alive packets in error or not received by endpoint before Time Out of the session

Fid:<Frequency ID> (optional)

Frequency ID (7 character – ICAO standard presentation e.g. 125.050 for 25kHz channel spacing or 118.005 for 8.33kHz channel spacing)

ptt-id:<PTT identity> PTT identity (value from 000001 to max. number of possible RTP streams, e.g.111111=63) assigned by GRS endpoint in 200OK response

rtphe:<RTPHE Version> 0 - 1

The Version of the used RTP HE.

TABLE 7 – SUPPORTED SDP TYPES AND PARAMETERS

3.6.1 SDP Message body attributes

3.6.1.1 Negotiation rules for SDP parameters

For standard SDP parameters like “m=” or “a=rtpmap”, the negotiation rules of the [RFC3264] SHALL be followed. For EUROCAE WG67 SDP parameters the following general rules for handling SDP attributes SHALL be applied as long as no more detailed requirements regarding SDP attribute handling is defined in the corresponding SDP attribute chapter. 1. In general, the SDP attribute rules and negotiation rules of the [RFC3265]

SHALL be followed. 2. A UAS receiving SIP INVITE messages including SDP attributes not supported

by its implementation (e.g.: “a=xyz:abc”) SHALL ignore the SDP attribute and SHALL accept the call.

3. A UAS receiving SIP INVITE messages including supported SDP attributes with unknown SDP attribute values (for example: “a=bss:abc”) SHALL accept the call but respond with the attribute values supported by its implementation.

3.6.1.2 SDP attribute – <send-receive mode>

Due to mandatory use of the R2S protocol between the User Agent at the VCS endpoint and the User Agent at the GRS endpoint, an INVITE request sent from the VCS to the GRS SHALL include a <send-receive mode> SDP attribute set to “sendrecv”. This allows a two-way RTP communication to be established with a GRS Transceiver, Transmitter or Receiver endpoint. In the case a <send-receive mode> SDP attribute is not present, it SHALL be assumed that its value is set to “sendrecv”. The GRS Transceiver, Transmitter or Receiver endpoints SHALL acknowledge the INVITE by sending a 200OK containing an SDP message body confirming the <send-receive mode> SDP attribute as ”sendrecv”.

© EUROCAE, 2012

26

3.6.1.3 SDP attribute – rtpmap:<payload type> <encoding name>/<clock rate

An INVITE request sent from the VCS endpoint to a GRS endpoint SHALL define the rtpmap SDP attribute with one or more <payload type>, <encoding name> and <clock rate> values. The following rtpmap parameter value is mandatory: • 123 R2S/8000 (for the R2S at 64kbps) In addition the following values are possible :( optional): • 0 PCMU/8000 or 0 X-PTT-PCMU/8000 (for the ITU-T G.711 PCM μ-

law codec at 64kbps) • 8 PCMA/8000 or 8 X-PTT-PCMA/8000 (for the ITU-T G.711 PCM A-

law codec at 64kbps) • 15 G728/8000 or 15 X-PTT-G728/8000 (for the ITU-T G.728 LD-

CELP codec at 16kbps) • 18 G729/8000 or 18 X-PTT-G729/8000 (for the ITU-T G.729 CS-

ACELP codec at 8kbps) The default <payload type> value SHALL be set to 8 within EUROPE. NOTE: All <encoding name> values with the prefix “X-PTT-“are still valid due to

backward compatibility reasons.

3.6.1.4 SDP attribute – type:<call type>

The SDP attribute describes the type of session or radio access mode (i.e. Idle, Receive, Transmit/Receive or Coupling). It SHALL be included in the SDP message body of an INVITE request sent from a User Agent at the VCS endpoint to a User Agent at the GRS endpoint. The SDP attribute “type” SHALL be set to one of the following values: • Radio-Idle • Radio-Rxonly • Radio-TxRx or Radio • Coupling The “a=type:Radio” is used to be backward compatible. A GRS endpoint SHALL check the “type” SDP attribute and reject the session establishment request, if they do not match with the following criteria. • Radio-Rxonly session to Radio Receiver or a combined GRS (Transceiver or

Receiver and Transmitter located at the same site and accessible from the IP network by one SIP URI)

• Radio-TxRx session to any GRS • Coupling session to any GRS • Radio-Idle to any GRS If the type of session matches with the GRS endpoint, the GRS endpoint SHALL acknowledge the INVITE by sending a 200 OK containing an SDP message body confirming the SDP attribute “type”. In case that the requested radio access mode doesn’t match, the SIP request SHALL be declined (603 Decline). NOTE: When a transmitter receives a SIP invite message with the session type

“Coupling”, that means that the transmitter has to allocate a Ptt-id to the corresponding VCS endpoint and has to accept any user PTT priority and Coupling PTT (see chapter 5.5.5).

If a type of a session changes after the SIP session establishment, (e.g. from a=type:Radio-Rxonly”, to a=type:Radio-TxRx”) a SIP Re-INVITE with the call-type SDP attribute set to the new value SHALL be used (i.e. Change of session parameters within a dialog). The GRS Transceiver, GRS Transmitter and GRS Receiver endpoint SHALL acknowledge the Re-INVITE by sending a 200 OK containing an SDP message body confirming the new call-type SDP attribute.

© EUROCAE, 2012

27

NOTE: In a SIP Re-INVITE message all other SDP parameters must also be sent to the GRS endpoint and the GRS endpoint has to acknowledge them in the 200 OK message.

A frequency can only be apart of one cross-coupled group. Once a GRS Transceiver, GRS Transmitter and GRS Receiver have acknowledged the “coupling” SDP attribute it SHALL reject (603 Decline) any further INVITE or Re-INVITE requests for it to be included in another cross-coupled group from SIP User Agents having different SIP URI addresses.

3.6.1.5 SDP attribute – txrxmode:<connection-type> (optional)

The optional SDP attribute “txrxmode” describes in which mode the radio equipment shall be work (receiver, transmitter, or transceiver/transmitter+receiver). Thus this “txrxmode” parameter defines also the audio transmission of the corresponding RTP communication link. It SHOULD be included in the SDP message body of an INVITE request sent from a User Agent at the VCS endpoint to a User Agent at the GRS endpoint. The SDP attribute “txrxmode” SHOULD be set to one of the following values: • Rx • Tx • TxRx This information will be used to define the role of the radio equipment for this radio call, NOTE: If the SDP attribute is defined as:

- “a=txrxmode:Rx ”this means that audio is only sent from GRS endpoint to the VCS endpoint - “a=txrxmode:Tx ”this means that audio is only sent from VCS endpoint to the GRS endpoint - “a=txrxmode:TxRx” this means that audio is sent in both direction from VCS endpoint to the GRS endpoint and vice versa.

In case of the following combinations of “txrxmode” to specific radio equipment that are not valid or don’t match, the SIP session request SHALL be declined. • “a=txrxmode:Tx to a Receiver ” • “a=txrxmode:Rx to a Transmitter ” If the “txrxmode” SDP attribute matches with the GRS endpoint, the GRS endpoint SHALL acknowledge the INVITE by sending a 200 OK containing an SDP message body confirming the SDP attribute “txrxmode”. In case however that “a=txrxmode:TxRx” was requested to a receiver, the GRS endpoint SHOULD answer with “a=txrxmode:Rx” in the 200 OK messages, since the radio doesn’t support TxRx role. In case that “a=txrxmode:TxRx” was requested to a transmitter, the GRS endpoint SHOULD answer with “a=txrxmode:Tx” in the 200 OK messages, since the radio doesn’t support TxRx role. This SDP attribute can be used to reduce the used bandwidth between GRS endpoints and VCS endpoints. The parameter SHOULD be used together with the “type” parameter in order to check if there is an invalid combination of these two parameters. The following combination of the “type” and “txrxmode” values is not valid: • “a=type:Radio-Rxonly” and “a=txrxmode:Tx” If the combinations of the “type” and “txrxmode” values are not valid the SIP request SHALL be declined (603 Decline). NOTE: A SIP session establishment to a GRS transmitter only (e.g., for ATIS

frequencies) can be achieved by setting the SDP attribute “type” to “a=type: Radio-TxRx” and the SDP attribute “txrxmode” to “a=txrxmode:Tx”.

© EUROCAE, 2012

28

3.6.1.6 SDP attribute – bss:<BSS quality index method> (optional)

Although the BSS attribute is optional, the feature is mandatory for the GRS and VCS endpoint. An INVITE request sent from a User Agent at the VCS endpoint to a User Agent at the GRS Transceiver or GRS Receiver endpoint MAY include <BSS quality index method> SDP attributes set to RSSI, AGC, C/N,PSD, or vendor specific methods as part of the SDP message body. If there is no “bss” SDP attribute in the SDP message body the GRS Receiver/Transceiver endpoint SHALL NOT include any BSS quality index values in the RTP HE. The BSS quality index method RSSI SHALL be supported by every GRS equipment. The GRS Transceiver or GRS Receiver endpoints SHALL acknowledge the INVITE by sending a 200 OK containing an SDP message body confirming the selected <BSS quality index method> SDP attribute as just one of the offered values. For the “bss” SDP attribute the following rules SHALL be applied: Á Non matching bss quality index methods between UAS and UAC SHALL still

allow to setup a call. Á If more than one bss quality index methods are negotiated, the UAC SHALL

use the first listed method that will be supported by the GRS. In case that the UAS does not support any offered bss quality index methods, it SHALL accept the call and SHALL respond in the 200OK messages with the SDP attribute value “a=bss:RSSI”

3.6.1.7 SDP attribute – sigtime:<signalling info time period>- (optional)

An INVITE request sent from the VCS endpoint to a GRS endpoint MAY include a “sigtime” SDP attribute with a <signalling info time period> set to a multiple of the RTP voice and R2S Keepalive packet interval as part of the SDP message body. The default “sigtime” value SHALL be “1”. If the “sigtime” attribute is defined in the SDP message body, the GRS endpoint SHOULD acknowledge the INVITE by sending a 200 OK also containing an SDP message body confirming the value given by the “sigtime” SDP attribute in the initial offer (send the same value back to the VCS endpoint). If the GRS endpoint doesn’t support this feature the GRS endpoint SHALL accept the call and SHALL respond in the 200 OK message with the default “sigtime” value or without the sigtime SDP attribute. NOTE: The default value of “1” implies that the Radio signalling information is sent

in the RTP header extension of every RTP voice packet (20ms default) and every R2S-Keepalive packet (200ms default).

3.6.1.8 SDP attribute - ptt_rep:<PTT OFF repetition>- (optional)

The “ptt_rep” value defines how many RTP voice packets are sent by the User Agent at the VCS endpoint with PTT-OFF following a transition of PTT state from PTT-ON to PTT OFF and how many RTP voice packets are sent by the User Agent at the GRS endpoint with SQUELCH OFF following a transition of SQUELCH state from SQUELCH ON to SQUELCH OFF. The Default value=0, implies that one RTP voice packet is sent with PTT-OFF, prior to R2S -Keepalive packets being sent with PTT-OFF and also that one RTP voice packet is sent with SQUELCH OFF, prior to R2S-Keepalive packets being sent with SQUELCH-OFF. An INVITE request sent from the VCS endpoint to the GRS Transceiver or GRS Transmitter endpoint MAY include a “ptt_rep” SDP attribute with a <PTT OFF repetition> set to a value from 0 to 3 as part of the SDP message body. The default “ptt_rep” value SHALL be “0”. If the “ptt_rep” attribute is defined in the SDP message body, the GRS endpoint SHALL acknowledge the INVITE by sending a 200 OK also containing an SDP message body confirming the value given by the “ptt_rep” SDP attribute in the initial offer.

© EUROCAE, 2012

29

If the GRS endpoint doesn’t support this feature, the GRS endpoint SHALL accept the call and SHALL respond in the 200OK message with the default “ptt_rep” value or without the ptt_rep SDP attribute.

3.6.1.9 SDP attribute - R2S–KeepAlivePeriod:<period>

An INVITE request sent from a VCS endpoint to a GRS endpoint SHALL include a “R2S-KeepAlivePeriod” SDP attribute with a value set between 20 and 1000 as part of the SDP message body. The unit of the value is millisecond. The default “R2S-KeepAlivePeriod” value SHALL be “200”. This implies that when there is no audio to be sent, “R2S-Keepalive packets” will be sent every 200ms. The GRS endpoint SHALL acknowledge the INVITE by sending a 200OK containing an SDP message body with the “R2S-KeepAlivePeriod” SDP attribute value received from the VCS endpoint. (Therefore, both directions use the same “R2S-KeepAlivePeriod” parameter) If the “R2S-KeepAlivePeriod” attribute is not delivered within the SDP of the SIP INVITE, the GRS endpoint SHALL use the R2S default values – although this is misbehaviour of the VCS endpoint. NOTE: The R2S-LocalHoldTime is the time an endpoint will wait to receive RTP

packets before disconnecting the RTP communication and clearing the established SIP session between the endpoints. R2S-LocalHoldTime (2 seconds default) =R2S-KeepalivePeriod (200ms default) x R2S-KeepaliveMultiplier (10 default).

3.6.1.10 SDP attribute - R2S-KeepAliveMultiplier:<multiplier>

An INVITE request sent from a VCS endpoint to a User GRS endpoint SHALL include a “R2S-KeepAliveMultiplier” SDP attribute with a value set between 2 and 50 as part of the SDP message body. The default “R2S-KeepAliveMultiplier” value SHALL be “10”. The R2S-KeepAliveMultiplier value is the number of R2S-Keepalive packets not received by an endpoint before LocalHoldTime counter expires and SIP Session times out. The default value of 10 implies that when an endpoint has not received 10 R2S-Keepalive packets, the session will timeout. The GRS endpoint SHALL acknowledge the INVITE by sending a 200OK containing an SDP message body with the “R2S-KeepAliveMultiplier” SDP attribute value received from the VCS endpoint. (Therefore, both directions use the same “R2S-KeepAliveMultiplier parameter)

3.6.1.11 SDP attribute – fid:<Frequency Identity>- (Optional)

Although the SDP attribute is optional, the Frequency Identity feature is mandatory for the GRS and VCS endpoint. Frequency Identity “fid” is an optional attribute. If sent it SHALL be defined using 6 digits and a decimal point after the 3 digit. Frequencies using either 25 kHz channel spacing (i.e. 128.075) or 8.33 kHz channel spacing (i.e. 129.005) SHALL be used. When receiving a fid value as part of the SDP message body sent with an INVITE request from the VCS endpoint towards a GRS endpoint, the GRS endpoint SHALL verify its value against the frequency configured within the GRS and reject session establishment request if SDP fid attribute does not match. The session rejection SHALL be done by sending the global failure response 603 Decline. The 603 Decline message SHOULD use the SIP reason cause=2002 If there is a match, the GRS endpoints SHALL acknowledge the INVITE by sending a 200OK containing an SDP message body confirming the received <fid> SDP attribute. If no “fid” attribute is configured on the GRS endpoint, the call SHALL be accepted, independent if a “fid” was received from the VCS or not. NOTE: This SDP parameter SHALL NOT be used to automatically tune multimode

GRS to its nominated frequency

© EUROCAE, 2012

30

3.6.1.12 SDP attribute - ptt-id:<PTT identity>

When a SIP Radio session is established between User Agents at the VCS and GRS Receiver, Transceiver or Transmitter endpoints, the GRS Receiver, Transceiver or Transmitter is responsible for assigning a ptt-id value to the User agent at the VCS endpoint. The ptt-id value SHALL be assigned only if the SDP parameter type <call type> (session type) has one of the following values: • Coupling • Radio-TxRx The ptt-id SHALL be communicated to the VCS endpoint in the 200 OK response from the GRS Receiver, Transmitter or Transceiver endpoint during session establishment in the following format: a=ptt-id:1 The ptt-id can take following numbers: 1, 2, 3, 4, 5, 6, 7 to 63 dependent of an internal radio order. Once a User Agent at a VCS endpoint has been assigned a ptt-id value by the endpoint and communicated through ptt-id attribute in the SDP message body, it SHALL set the same value within the ptt-id field of the RTPTx header extension for all RTP packets or R2S-packets sent towards the same Receiver, Transceiver or Transmitter (refer to chapter 0 for further details). Likewise a User Agent at a VCS endpoint with a SIP session established with the GRS Receiver, Transceiver/Transmitter endpoint SHALL also be notified of the ptt-id of the User Agent currently transmitting at the GRS Transceiver/Transmitter through information sent by the GRS endpoint in the ptt-id field of the Receive Path RTP Header Extension (see chapter 0 RTP Header extension). In the case that a GRS Transceiver/Transmitter is configured for audio summation, the User Agent at a VCS endpoint SHALL still be notified of the ptt-id of just one of the multiple User Agents currently transmitting at the GRS. In the case of an incoming aircraft call, the GRS Receiver/Transceiver endpoint SHALL set the ptt-id in the RTPRx header extension to ptt-id=0.

3.6.1.13 SDP attribute – rtphe:<RTPHE Version>

An INVITE request sent from the VCS endpoint to the GRS endpoint SHALL include an “rtphe” SDP attribute with the value 1. If the GRS endpoint supports the new RTP header extension it SHALL acknowledge the INVITE by sending a 200OK containing an SDP message body confirming the received <rtphe> SDP attribute. If the radio only provides the old ED-137 protocol (Version August 2009), it will ignore this parameter and sends back an SIP 200 Ok message with “a=rtphe:0” or without a “rtphe” SDP attribute. When the VCS receives this response it should release the SIP session if it only supports the new RTP HE or else it switches to the old ED-137 protocol specifying this old RTP HE.

3.6.1.14 SDP attribute – ls-pl:<linked session protection value> (optional)

The SIP INVITE request of a linked session SHALL include the SDP parameter “ls-pl. The SIP INVITE request of a normal session SHALL NOT include the SDP parameter “ls-pl. If the GRS endpoint supports the linked session functionality, it SHALL acknowledge the INVITE by sending a 200OK containing an SDP message body confirming the received <ls-pl> SDP attribute. The linked session protection attribute “ls-pl” has the following possible values: • LSDeletionDisabled (default value) • LSDeletionEnabled The value <LSDeletionDisabled> prohibits the deletion from other SIP sessions in the same linked session set The value <LSDeletionEnabled> allows the deletion from other SIP sessions in the same linked session set

© EUROCAE, 2012

31

3.6.1.15 SDP attribute – ls-execute:<linked session execution value> (optional)

An INVITE request sent from a User Agent at the VCS endpoint to a User Agent at the GRS endpoint may include an optional linked session protection attribute “ls-execute” with the possible values: • KeepLS (default value) • DeleteLS If the “ls-execute” parameter has the value “KeepLS” the GRS endpoint SHALL keep all other SIP sessions within the Linked Session Set. If the “ls-execute” parameter has the value “DeleteLS” the GRS endpoint SHALL close all other SIP sessions within the Linked Session Set that were established with the “linked-session” parameter set to “LSDeletionEnabled”. In the SIP BYE message the reason header value SHALL be set to “linked session clear command”

3.7 ADDRESS FORMAT

5 [SIP] SIP Address Format As specified in RFC 3261 [12], the formal syntax for a SIP and SIPS URI is defined as follows: SIP-URI = “sip:” [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = “sips:” [ userinfo ] hostport uri-parameters [ headers ] For ATS purposes, it is RECOMMENDED that SIP URI for a GRS Transceiver, GRS Transmitter and GRS Receiver endpoint respectively MAY be defined as follows: sip:txrx.frequency.atsu@radio_site_id.local_domain sip:tx.frequency.atsu@radio_site_id.local_domain sip:rx.frequency.atsu@radio_site_id.local_domain sip: tx.m.frequency.atsu@radio_site_id.local_domain sip: tx.s.frequency.atsu@radio_site_id.local_domain For User Roles the addressing format MAY be defined as follow: sip:[email protected]_icao_id.local_domain For details, please refer to RFC 3261 [12]

3.8 SIP CONNECTION FACILITIES

3.8.1 Basic call functionalities

6 [SIP] Basic call functionalities

3.8.1.1 Routine Radio Call

7 [SIP] Normal SIP session establishment SIP session establishment request sent by a VCS endpoint to a Ground Radio Station endpoint in normal operational conditions SHALL use a SIP Priority Header field set to “normal” and a SIP subject header field set to “radio”. A GRS endpoint SHALL be able to accept up to the configured number of (configured by the management system) SIP sessions, but it SHALL support at least two concurrent SIP sessions. A GRS endpoint SHALL accept SIP session establishments employing the SIP Priority Header field set to “normal” and SIP subject header field set to “radio A GRS endpoint with the maximum number of SIP sessions already established employing the SIP Priority Header field set to “normal” and SIP subject header field set to “radio” SHALL reject a further request for SIP session establishment that defines the SIP Priority Header field set to “normal” and SIP subject header field set to “radio”.

© EUROCAE, 2012

32

The rejection SHALL indicate the cause as to why the SIP session establishment request was refused. The establishment and clearing of a normal SIP session SHALL be handled as specified in RFC 3261 [12] and RFC 3665 [23].

3.8.1.2 Emergency SIP session establishment to a Ground Radio Station

8 [SIP] Emergency SIP session establishment SIP session establishment request sent by a VCS endpoint to a Ground Radio Station endpoint in abnormal operational conditions (i.e. an emergency situation concerning the safety of aircraft) MAY use a SIP Priority Header field set to “emergency” and a SIP subject header field set to “radio”. It SHALL NOT be possible to pre-empt a SIP session that was established employing the SIP Priority Header field set to “emergency” and SIP subject header field set to “radio”. The establishment and clearing of an emergency SIP session SHALL be handled as specified in RFC 3261 [12] and RFC 3665 [23].

3.8.1.3 SIP Session pre-emption

The Priority facility is a means to force access to a GRS endpoint for high priority or emergency calls (e.g. if a radio resource is already blocked by other users and a new one wants to access this resource). If the INVITE includes the Priority header field with value “emergency” and the GRS does not allow an additional radio session, the device SHALL interrupt a session with a lower priority and accept this high priority session. If there is no normal SIP session to interrupt, the session request SHALL be rejected. The session to be interrupted SHOULD be a session that currently has no active voice (i.e. PTT OFF and/or Squelch OFF). An emergency coupling session request SHALL pre-empt a normal coupling session, if existing, independently, if the maximum number of sessions is reached or if PTT is active. If the pre-empted session is a linked session, all SIP sessions of this linked session SHALL be closed (see chapter 0). An emergency non-Coupling request at a GRS endpoint SHALL interrupt one normal SIP session by applying the following order: 1) If exists, a SIP session in Radio-Idle mode, which is not part of a linked session 2) If exists, a SIP session in Radio-Idle, which is part of a linked session and the

active session of this linked session is in Radio-Rxonly mode 3) If exists, a SIP session in Radio-Idle, which is part of a linked session and the

active session of this linked session is in Radio-TxRx mode 4) If exists, a SIP session in Radio-Rxonly mode 5) If exists, a SIP session in Radio-TxRx mode.

3.8.1.4 Radio-Idle session

This type of radio access mode reduces the consumed bandwidth to the GRS endpoint, since no voice information is exchanged between the GRS endpoint and the VCS endpoint. The session type (“a=type:Radio-Idle”) SHALL be possible to any GRS endpoint. If a “Radio-Idle” session is established between a VCS and a GRS endpoint, only R2S-keepalive packets SHALL be exchanged. The VCS endpoint SHALL NOT send PTT-ON, PTT Mute or Relative Time Delay Information to the GRS endpoint. The GRS endpoint SHALL send all status information to VCS endpoint.

© EUROCAE, 2012

33

3.8.1.5 Linked Session Management

The Linked Session functionality provides to the GRS endpoint the opportunity to detect SIP sessions which are coming from the same user but from different equipment in order to guarantee higher service availability. Definition: All SIP sessions at a GRS endpoint, which have in the SIP From URI the same user part and the “ls-pl” SDP parameter included in the SIP INVITE request, shall be combined in the same linked session, independent of the radio access mode (Idle, Receive, Transmit/Receive or Coupling). The SIP INVITE request of a linked session SHALL include the SDP parameter “ls-pl” in order to distinguish normal SIP sessions from linked SIP sessions, The GRS endpoint SHALL allow more than one coupling session within a linked session. (see Table 8

Table 8

) The linked session functionality enables the GRS endpoint to support a specific handling of redundant connections between a VCS endpoint and a GRS endpoint. A GRS endpoint with enabled linked session functionality SHALL support at least 4 SIP sessions and its corresponding RTP streams. The linked session functionality enables the GRS endpoint support redundant connections between VCS endpoint and GRS endpoint for all types of connections. If the linked session SIP request exceeds the session limit configured at GRS, the GRS SHALL send a 603 DECLINE With the WG-67 reason cause=2008. (see

). The GRS transmitter/transceiver endpoint SHALL ensure that from each SIP session of a linked session only one RTP stream is forwarded to the antenna even if the radio is configured in “summation mode”. NOTE: The PTT priority rules are valid within linked session and between linked

session and other session. In order to enable the possibility to delete SIP sessions and its corrupted RTP streams new optional SDP attributes “ls-pl” and “ls-execute” shall be introduced, which allows the VCS endpoint to disconnect the other sessions of a linked session set. (see chapter 0) It SHALL be possible at the GRS endpoint to disable or enable the linked Session functionality. NOTE: Typically such a function can be enabled/ disabled by the Management

System of the GRS endpoint. If the linked session functionality will be disabled by the management system at a GRS endpoint, the GRS endpoint SHALL close all SIP sessions that are part of a linked session by sending a SIP BYE message with the WG67 reason cause=2010 (“linked session disabled” - see Table 9). If the linked session functionality is disabled at the GRS endpoint, the GRS endpoint SHALL NOT combine any SIP sessions into linked sessions. If the linked session functionality is disabled and the GRS endpoint receives a SIP INVITE request for a linked session, the GRS endpoint SHALL send a 603 DECLINE with the WG-67 reason cause=2010. (“linked session disabled” – see Table 9)

3.8.2 Interaction with Other ATS Supplementary Services

The following section lists some restrictions, which are applicable at the GRS and VCS equipment.

3.8.2.1 Call Priority Interruption

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be selected for interruption by a SIP telephone User Agent at a VCS endpoint or VCS gateway

© EUROCAE, 2012

34

3.8.2.2 Call Intrusion

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be subjected to a Call Intrusion by a SIP telephone User Agent at a VCS endpoint or VCS gateway.

3.8.2.3 Call Pickup

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be subjected to a Call Pickup by a SIP User Agent at a VCS endpoint or VCS gateway.

3.8.2.4 Call Hold

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be subjected to a Call Hold by a SIP User Agent at a VCS endpoint or VCS gateway.

3.8.2.5 Call Transfer

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be subjected to a Call Transfer by a SIP User Agent at a VCS endpoint or VCS gateway.

3.8.2.6 Conference

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be included in any Conferences by a SIP User Agent at a VCS endpoint or VCS gateway.

3.8.2.7 Call Forwarding

A SIP session established between a VCS endpoint and a GRS endpoint SHALL NOT be subjected to a Call Forwarding by a SIP User Agent at a VCS endpoint or VCS gateway.

3.8.2.8 Position Monitor

The Position monitoring service that enables a telephone user to subscribe to a dialogue package and be notified of dialogs in progress at other user terminal (CWP) SHALL NOT be applied to GRS endpoints. A user SHALL NOT be able to monitor audio transmitted and received by a GRS endpoint.

3.8.3 AUDIBLE TONES

9 [SIP] SIP Audible Tones control Normally all SIP User Agents must be capable of providing users with audible tones in order to indicate call progress following the receipt of signalling messages in different call states. As GRS equipment is connected automatically on receipt of a SIP session establishment request, audible tones SHALL NOT be generated.

3.8.4 SIP Radio Session establishment Procedure

10 [SIP] SIP Radio session establishment procedure The following is a generic example describing the Message Sequence for a successful establishment of a SIP session initiated by a User Agent A1 at the VCS endpoint to a User Agent B1 at the GRS Transceiver endpoint.

© EUROCAE, 2012

35

UA_A1 at VCS Enpoint

UA_B1 at GRS endpoint

INVITE (F1)

Two way RTP Session

100 Trying (F2)

ACK (F4)

Call is automatically answered 200OK (F3)

Connected

Rx path

FIGURE 4: EXAMPLE OF SUCCESSFUL SIP SESSION ESTABLISHMENT BETWEEN VCS ENDPOINT AND GRS TRANSCEIVER ENDPOINT

1. INVITE (F1) The User Agent A1 at the VCS endpoint sends an INVITE request message containing the following: From: and To: SIP URI addresses, a Call_ID used to identify the call, Cseq command sequence header, the Contact address of the User Agent A1, a Max-forwards value of 70 (used to avoid SIP Radio session requests entering a loop), a Subject header defined as “radio” and a Priority header defined as “normal”. The content type defines an SDP message body is being carried with the INVITE method. 2. 100Trying (F2) The User Agent B1 at the GRS endpoint MAY respond with a 100Trying provisional response containing the same From: and To: SIP URI addresses, the same Call_ID used to identify the SIP Radio session, the same Cseq command sequence header and no SDP message body included. 3. 200 OK (F3) The User agent B1 at the GRS endpoint on receiving the INVITE request message SHALL verify its SIP contents and SDP message body contents. If the GRS endpoint has sufficient resources and the correct media capabilities etc in order to accept the SIP session establishment request, it will answer with a 200OK final response message, containing an SDP message body that confirms the negotiated designated media capabilities and attributes between the two endpoints. This 200OK final response from User Agent B1 at the GRS endpoint indicates that the SIP Radio session request has been automatically answered. This response contains the same From: and To: SIP URI addresses, the same Call_ID used to identify the SIP Radio session, the same Cseq command sequence header, the Contact address of the User Agent B1. The content type defines an SDP message body is being carried with the 200OK response. 4. ACK (F4) The User Agent A1 at the VCS endpoint then sends an ACK request message containing the same: From: and To: SIP URI addresses, the same Call_ID used to identify the SIP Radio session, a new Cseq command sequence header for the ACK, the Contact address of the User Agent A1, a Max-forwards value of 70 (used to avoid call loops). The content type defines that no SDP message body is being carried with the ACK method.

© EUROCAE, 2012

36

3.8.5 SIP Radio Session request verification

SIP signalling traffic must be viewed with considerable suspicion, malformed SIP messages should be discarded. A session request initiated from a GRS endpoint to a VCS endpoint SHALL NOT be allowed.

3.8.5.1 SIP Radio Session Rejection

A GRS endpoint SHALL reject an incoming SIP Radio session request on several conditions, as listed in the following table.

Condition Reject Message Reason Header Values (optional)

SIP Radio session request from unknown calling party address. The SIP INVITE from-field needs to be checked and compared against a permissions list.

603 Decline

SIP Radio session request to an invalid frequency (fid): The SDP Attribute “fid” does not match.

603 Decline cause= 2002

SIP Radio session request with the SDP Attribute “a=type: coupling” and there is already one session or one linked session with the call type “coupling” established.

603 Decline cause=2005

SIP Radio session request with the SDP Attribute “a=type:” doesn’t match with the radio equipment (see 0).


Invalid Combination of SDP parameters (e.g. “type” and “txrxmode” doesn’t match)


The GRS endpoint (e.g. Is in the maintenance mode.


The SIP INVITE to-field differs from local SIP user address,

404 Not Found

Unknown or Unsupported voice codec 415 Unsupported Media Type

Normal SIP Radio session request exceeds session limit configured at GRS.


Linked session SIP request to a GRS with disabled linked session functionality.


TABLE 8 – SUPPORTED SIP RESPONSES

© EUROCAE, 2012

37

3.8.5.2 SIP Radio Session clearing

The VCS and Radio station sides SHALL be able to clear a session. A GRS endpoint shall only be allowed to clear a SIP radio session in the situations listed in chapter 3.3.4. Table 9 lists all Reason header values that SHOULD be supported for SIP BYE and SIP 603 Decline messages:

Protocol cause Text WG-67. 2000 “session pre-emption” WG-67. 2001 “missing R2S KeepAlive” WG-67 2002 “fid does not match” WG-67 2003 ”radio in maintenance mode” WG-67 2004 ”internal error” WG-67 2005 ”coupling not allowed” WG-67 2006 “radio access mode doesn’t match” WG-67 2007 “parameter error” WG-67 2008 “limit exceeded” WG-67 2009 “linked session clear command” WG-67 2010 “linked session disabled”

TABLE 9 – SUPPORTED REASON HEADER VALUES

3.8.5.3 Verification of Incoming SIP Radio Session request to local SIP User

The destination SIP URI Username (part of the “To” field in the SIP INVITE header) SHALL be checked according to the configured SIP URI of an UAS. The system SHALL reject an incoming SIP Radio session request if the destination username in the SIP INVITE does not match with the locally configured SIP user. In this case, the reject reason 404 defined in Table 8 SHALL be used. This check SHALL be applied as case insensitive string compare.

3.8.5.4 Permissions list check on Incoming SIP Radio session requests

The GRS endpoint SHOULD allow to disable the Permissions list check on incoming SIP Radio sessions. In this case, incoming SIP Radio session requests from all users are accepted (and not rejected). The GRS endpoint SHALL allow to enable a Permissions list check feature. In this case, all incoming SIP Radio session requests with the SIP Priority Header field set to “emergency” (emergency radio call) SHALL be checked against the “Emergency Radio Call” permissions list. All incoming SIP Radio session requests with the SIP Priority Header field set to “normal” (radio call) SHALL be checked against the “Radio Call” and the “Emergency Radio Call” permission list (Both lists are typically configured by the Management System). NOTE: A normal radio call shall be checked against both permission lists because

it is assumed that a user which is allowed to establish an emergency radio call shall also be allowed to establish a normal radio call.

These checks SHALL be applied as a case insensitive string comparison. The Permission list checks SHALL be applied to the Username part of the “From” field of the received SIP INVITE message (Source URI Username from the originator). The GRS endpoint SHALL reject an incoming SIP Radio session request in the case that the permission list check is enabled and there is no matching entry in the corresponding Permission Lists. The reject message SHALL be 603 Decline, please refer to Table 8.

© EUROCAE, 2012

38

CHAPTER 4

AUDIO

4.1 INTRODUCTION

Audio transmission over an IP network SHALL employ the Real time Transport Protocol as defined by RFC3550 [21] . A new Header extension field has been defined for the Real time Transport Protocol that SHALL be used to transport, among others, the following Radio signals in real time: • Different PTT types, PTT identification, Climax-Time delay values on the

transmit path from the VCS endpoint towards GRS Transceiver or Transmitter endpoint

• Squelch ON/OFF indication, BSS quality index method, BSS quality index value, Simultaneous Transmission Detection on the receive path from GRS Transceiver or Receiver endpoint towards the VCS endpoint.

4.2 AUDIO SPECIFICATION

4.2.1 Audio Level

1 [AUDIO] Audio level specification The GRS transmitter SHALL produce a 30% AM modulated RF output signal, when a –10dBm0 +/- 1dB audio input level is applied in the digital domain. The GRS receiver SHALL produce a –10 dbm0 +/- 1dB audio output level when a 30% AM modulated RF signal is applied at the RF input. For Europe, the audio levels of a GRS transmitter and GRS receiver SHALL meet the standard defined in ETSI EN 300 676-1 V1.4.1. [41]

4.2.2 Audio Quality

4.2.2.1 Qualification of the communication

2 [AUDIO] Voice quality The voice quality of a radio communication is defined using a voice quality estimation methodology nominated “Mean Opinion Score” (MOS) rating. The MOS scale was formulated as the result of subjective studies. In subjective testing, subjects are requested to classify the perceived voice quality into categories (MOS rates the quality of the voice signal in one of the following categories: excellent (5), good (4), fair (3), poor (2) and bad (1)). To minimize the consequence of voice degradation, the MOS value of the Radio Call over the ground segment to and from the GRS endpoint SHALL be equal or better than 4;

4.2.2.2 Delay introduced by audio processing and propagation

3 [AUDIO] Voice latency time performance The transmission time for connections with digital segments comprises of delay due to equipment processing as well as propagation delay, such that both types of delay can be significant contributors to overall transmission time. As these delays may introduce some detrimental effects on service quality, the system engineering SHALL respect the ITU-T Recommendation G.114.

4.2.2.3 Voice Packetization

4 [AUDIO] Voice Packetization interval requirements The VCS and GRS endpoints SHALL communicate using voice packet sizes of 10, 20 or 30ms. The default voice packet size SHALL have duration of 20 ms.

© EUROCAE, 2012

39

4.2.3 Voice Coding

5 [AUDIO] Voice coding requirement The VCS and GRS endpoint SHALL support voice coded according to ITU-T G.711 PCM A-law or µ-law G.711 PCM. In order to improve robustness, the ITU-T G.711PLC codec [34] MAY be used; The VCS and GRS endpoint SHOULD support voice compression according to one of the following algorithms: • ITU-T G.728 [35] LD-CELP algorithm. • ITU-T G.729 [36] CS-ACELP algorithm.

4.3 GUIDELINES FOR SAMPLE-BASED AUDIO CODECS

Among others, the RFC 3551 [22] standard defines the following guidelines for sample-based audio codecs: • An RTP voice packet MAY contain any number of voice samples, subject to the

constraint that the number of bits per sample multiplied by the number of samples per packet yields an integral octet count.

• The RTP timestamp reflects the instant at which the first sample in the packet was sampled, that is, the oldest information in the packet.

4.4 AUDIO CODECS

The Audio codecs and payload type numbers shown in Table 10 are defined by RFC 3551 [22].

Audio Codec name

Payload type

sample/ frame

bits/ sample

Sampling rate

ms/frame Default packet size (ms)

PCMU 0 Sample 8 8,000 20

PCMA 8 Sample 8 8,000 20

G.728 15 Frame N/A 8,000 2.5 20

G.729 18 Frame N/A 8,000 10 20

TABLE 10 – PROPERTIES OF AUDIO CODECS (RFC 3551 P.10, P.28)

© EUROCAE, 2012

40

CHAPTER 5

RTP: REAL-TIME TRANSPORT PROTOCOL

5.1 REAL-TIME TRANSPORT PROTOCOL - GENERAL ISSUES

The Real time Transport Protocol SHALL be used to transport RTP packets containing either audio/signalling or just signalling in real time over an IP network. The Real time Transport Protocol SHALL also be used by Real Time Session Supervision in order to transport R2S-Keepalive packets containing signalling in real time over an IP network (refer to CHAPTER 6 for further details). RTP is defined by IETF RFC 3550, but does not provide any quality of service mechanism over the IP network as RTP packets are handled in the same way as all other packets in an IP network. However, RTP does allow detection of some impairment introduced by an IP network, such as: • Packet loss • Variable transport delay • Out of sequence packet arrival

5.1.1 Basic System Topology

1 [RTP] RTP Audio and Radio Signalling protocol requirement Within an IP-network, the audio transmission and specific radio signalling (refer to Note below) SHALL be performed by the Real-time Transport Protocol (RTP). The RTP defines the transport layer for the voice packets and SHALL conform to RFC 3550 [21]. The same RFC also defines a Real Time Control Protocol (RTCP) that MAY be employed to monitor the quality of service and to convey information about the participants in an on-going session. NOTE: Radio signalling includes specific real time radio information such as PTT

type, Squelch, Signal Quality Information for BSS, Climax Time Delay, Simultaneous Transmission detection etc.… needed to monitor and control GRS equipment. This information is conveyed in the RTP packet header using the RTP header extension field.

5.1.2 RTP-Payload Types compliant with RFC 3551

The RFC 3551 [21] describes a profile for the use of the “Real-time Transport Protocol” (RTP) and the associated “Real Time Control Protocol” (RTCP) within audio and video multi-party conferences using minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. 2 [RTP] RTP Profile specific items requirement In the RFC 3551 [22], the items identified within RFC 3350 [21] which have to be defined in a specific profile are stated as follows:

Item RFC 3551

RTP data header Standard format of RTP data header

RTP data header additions No additional fixed fields

RTP data header extensions No RTP header extension defined

RTCP packet types No additional RTCP packet types

RTCP report interval The suggested constants are to be used for the RTCP report interval calculations.

SR/RR extension No extension

SDES use Applications may use any of the SDES items described in RFC 3550 [21].

Security Default security services

© EUROCAE, 2012

41

Item RFC 3551

String-to-key mapping No specific mapping

Congestion RTP and this profile may be used in the context of enhanced network service or they may be used with best effort service

Underlying protocol RTP over unicast and multicast UDP or TCP

Encapsulation Application specific possible

TABLE 11 – PROFILE SPECIFICATION OF RFC 3550

5.1.3 Independent Encoding Rules for Audio

3 [RTP] RTP Encoding Rules Discontinuous transmission (silent suppression) SHALL NOT be applied independent of the used audio payload format;

5.1.4 Port Assignment

4 [RTP] RTP and RTCP UDP Port number In RFC 3551 [22] the following information is provided concerning the port assignment: As specified in the RTP protocol definition RTP data SHOULD be carried on an even UDP port number and the corresponding RTCP packets SHOULD be carried on the next higher (odd) port number. Applications MAY use any such UDP port pairs.

5.2 OPERATING RECOMMENDATIONS

5.2.1 PTT transmission performance

5 [RTP] RTP PTT transmission performance PTT signal is used to activate transmission at the GRS transceiver/transmitter. It is activated when the controller at the VCS endpoint selects the PTT key at the Controller Working Position. In order to guarantee the correct activation of the GRS transmitter, the transmission of voice and to avoid sending useless RTP packets with voice payload, voice packets SHALL be sent from ,the VCS interface to the Radio Interface only when PTT has been activated. The PTT signal defined within the RTP header extension field SHALL be transmitted by the VCS endpoint to the GRS endpoint as soon as the controller at the VCS endpoint has activated the PTT key at the controller working position.

5.2.2 Squelch transmission performance

6 [RTP] Squelch transmission performance Squelch) signal is active when the GRS transceiver/receiver detects an incoming radio call. The Squelch signal defined within the RTP header extension field SHALL be sent by the GRS endpoint to the VCS endpoint as soon as the GRS endpoint has detected the incoming call. In order to guarantee the correct reception of the voice and also to avoid sending RTP audio packets when SQUELCH is not activated (hence no voice being received), RTP audio packets SHOULD be sent from the GRS endpoint to the VCS endpoint only when the Squelch has been activated.

© EUROCAE, 2012

42

5.2.3 Class of Service (CoS) and Quality of Service (QoS)

7 [RTP] RTP Class of Service Each GRS endpoint SHALL support Differentiated Services (DiffServ) as defined by RFC 2474 [9] and RFC 2475 [10]), in such a way that each different traffic type can be marked with a specific DSCP (Differentiated Service Code Point) value. The mapping of DSCP values to traffic type SHALL be configurable. Layer 2 QoS mechanisms (IEEE 802.3p/802.3q) are OPTIONAL. The assignment of the DSCP values to the different traffic types is defined by EUROCAE ED-138 Part1: Network Specification document [38].

5.3 RTP HEADER

This section provides a brief overview of the fields within the RTP header version 2 as specified by RFC 3550 [21]: 8 [RTP] RTP Header specifications

0 2 3 4 8 9 16 31 V=2 P X CC M PT Sequence number

Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) list

........

FIGURE 5: RTP HEADER (RFC 3550 P.12)

Version (V): This field identifies the RTP version. Its value SHALL be equal to 2. Padding-Bit (P): Its value SHALL be equal to 0 if no additional octets are added at the end of the telegram. Extension (X): The extension bit SHALL be set, the fixed header SHALL be followed by exactly one header extension CSRC count (CC): The CSRC count contains the number of RC identifiers that follow the fixed header. Marker (M): The interpretation of the marker is defined by a profile. Payload type (PT): This field identifies the format of the RTP payload. The value of this field matches the profile number listed in the SDP This field identifies and determines the interpretation by the application. Sequence number: The sequence number increments by one for each RTP data packet sent, and MAY be used by the receiver to detect packet loss and to restore the packet sequence. Time stamp: The timestamp reflects the sampling instant of the first octet in the RTP data packet. SSRC: Synchronization Source Identifier (SSRCI): This 32-bit field identifies the synchronization source (sender) of the RTP packet. At the start of a session, each participant SHOULD choose its SSRC number randomly. Should two participants choose the same number, they each choose again until each party is unique. CSRC: Contributing Source Identifier: The CSRC list identifies the contributing sources for payload contained in this packet. There can be none or up to 15 instances of this 32-bit field in the header. The number is set by the CSRC Count (CC) header field. This field is only present if the RTP audio packet is being sent by a mixer, which has received RTP audio packets from a number of sources and sends out combined packets. The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted by a mixer and the CC-field is set correspondingly.

© EUROCAE, 2012

43

5.5 REAL-TIME TRANSPORT PROTOCOL HEADER EXTENSION (RTP-HE)

The RTP header extension (RTP-HE) is used for continuous transmission of Ground Radio Station specific signalling (i.e. PTT type, SQL, Signal Quality Information for BSS, PTT Mute, PTT summation, Simultaneous Radio Call detection, Climax time delay etc.) together with audio within an established RTP communication. This chapter will define how the RTP Header Extension is used for the real time transport of Radio signalling between VCS and GRS endpoints within a network used for radio communications. Any VCS endpoint communicating with a GRS (receiver, transmitter, or transceiver) endpoint should at least support a basic set of radio signalling information to be exchanged between these endpoints. This basic set should define the mandatory minimum information necessary for communicating with a GRS. This chapter will therefore provide a description of the mandatory radio signalling information and the mechanism of how additional features are transported within the RTP header extension in order to offer a flexible method through which ATC services can be provided in the future. As stated in RFC 3550 [21], the header extension mechanism is provided to allow individual implementations to develop new payload-format-independent functions that require additional information to be carried in the RTP packet header. For correct interoperability between the VCS and GRS endpoints it is expected that implementations SHALL incorporate the RTP Header extension. The RTP header extension may be ignored by other implementations that have not implemented it, but in this case correct interoperability could not be achieved.

5.5 RTP HEADER EXTENSION FOR RADIO APPLICATIONS

This section describes how the RTP header extension is employed for radio applications. The specification is limited to the structure of the RTP Header extension in order to transport radio signalling information.

5.5.1 RTP Header Extension packet types

Using the header extension solution, the following 2 different types of packets are therefore possible: • Packets containing Audio payload and signalling • Packets containing Signalling without audio payload. These packets are called

R2S “Keep alive “packets and are described further in 0. Figure 6 provides an example of the different RTP packet types.

FIGURE 6: RTP PACKETS TYPES

© EUROCAE, 2012

44

5.5.2 GRS Transceiver/transmitter PTT activation/ de-activation

9 [RTP] RTP Radio PTT activation/de activation PTT information is conveyed within the RTP header extension of the RTP packet sent from the VCS endpoint to the GRS transceiver/transmitter endpoint. When PTT is not active, the RTP packet SHALL include the PTT-OFF information in the RTP header extension of the RTP packet, but the RTP payload SHOULD NOT include audio samples. When PTT is active, the RTP packet SHALL include the PTT-ON information in the RTP header extension of the RTP packet and the RTP payload SHOULD include audio samples. When a GRS transceiver/transmitter endpoint receives the first packet with PTT-ON information the GRS transceiver/transmitter endpoint SHALL confirm with a R2S-Keepalive packet with PTT-ON information within a certain maximum confirmation delay. NOTE: The confirmation delay is introduced in order to give the ANSPs the

possibility to define a value for this delay and to test this value. From the functional point, the GRS endpoint shall immediately confirm a PTT-ON event with the corresponding R2S packet, as described above. The confirmation delay is defined as the time between the GRS endpoint receiving an event on the IP interface in the RTPTx direction and sending the corresponding confirmation on the IP interface in the RTPRx direction

In the case that PTT is active and new radio signalling information or the Radio Remote control information is transported via the RTP HE of an RTP audio packet from the VCS endpoint to the GRS Transceiver/Transmitter endpoint, the VCS endpoint SHALL include info in next audio packet and the GRS Transceiver/Transmitter endpoint SHALL: respond with a R2S-Keepalive packet within the maximum confirmation delay. NOTE: The confirmation delay is introduced in order to give the ANSPs the

possibility to define a value for this delay and to test this value. From the functional point, the GRS endpoint shall immediately confirm a PTT-ON event with the corresponding R2S packet, as described above. The confirmation delay is defined as the time between the GRS endpoint receiving an event on the IP interface in the RTPTx direction and sending the corresponding confirmation on the IP interface in the RTPRx direction

An example of a PTT ON/OFF transmission timing-diagram is shown in Figure 7 below.

© EUROCAE, 2012

45

FIGURE 7: TRANSMISSION TIMING DIAGRAM

© EUROCAE, 2012

46

5.5.2.1 GRS Transceiver/Transmitter PTT de-activation event

In order to improve the detection of the PTT deactivation event, RTP packets with a RTP header extension defining PTT deactivation SHOULD be repeated a number of times (e.g. 3 times. i.e. ptt_rep:2) in a short period. From this point onwards R2S KeepAlive packets with an RTP header extension SHALL be sent at least with the R2S-Keepalive period (i.e. default 200ms). In the case however that PTT is deactivated and new radio signalling information or the radio remote control information is transported via the RTP HE of an R2S packet, the VCS endpoint SHALL send an R2S-Keepalive packet within the maximum command delay and the GRS Transceiver/Transmitter endpoint SHALL also respond with a R2S-Keepalive packet within the maximum confirmation delay. NOTE: The command delay is introduced in order to give the ANSPs the

possibility to define a value for this delay and to test this value. From the functional point, the VCS endpoint shall immediately send a PTT-OFF event with the corresponding R2S packet, as described above. The command delay is defined as the time when the VCS endpoint receiving an event on an internal interface and sending the corresponding command on the IP interface in the RTPTx direction

NOTE: The confirmation delay is introduced in order to give the ANSPs the possibility to define a value for this delay and to test this value. From the functional point, the GRS endpoint shall immediately confirm a PTT-ON event with the corresponding R2S packet, as described above. The confirmation delay is defined as the time between the GRS endpoint receiving an event on the IP interface in the RTPTx direction and sending the corresponding confirmation on the IP interface in the RTPRx direction

FIGURE 8: SIGNALLING STATUS OPERATING MODE

The “Signalling Info Time Period” TR (default 1) defining how often PTT-ON or PTT-OFF signalling info is sent in the RTP header extension of RTP audio or R2S-Keepalive packets and the number of signalling deactivation indications required to stop transmission “ptt_rep: <PTT OFF Repetition>” (default 0), SHOULD be defined by the SDP attribute negotiation during the SIP session establishment or through a management session. Otherwise the default values defined in Table 7 SHALL be applied.

© EUROCAE, 2012

47

5.5.2.2 Transmit Path RTP audio to R2S-Keepalive packet transition

When a VCS endpoint activates PTT in order to transmit audio, it SHALL send an RTP audio packet with RTP Header Extension set, e.g., to ptt_type=PTT ON and PT=Codec Number type (i.e. PT=8 for G.711 codec) towards the GRS Transceiver/Transmitter endpoint every RTP audio packet period (i.e. default value 20ms). When a VCS endpoint deactivates PTT in order to stop audio transmission, it SHALL send at least one RTP audio packet with RTP Header Extension set to ptt_type=PTT OFF and PT=Codec Number type (i.e. PT=8 for G.711 codec) towards the GRS Transceiver/Transmitter endpoint. The optional SDP attribute – “ptt_rep” defines how many additional RTP audio packets SHALL forward the PTT OFF information towards the GRS Transceiver/Transmitter endpoint. If the VCS endpoint activates PTT in the meantime, the VCS endpoint SHALL send an RTP audio packet with PTT ON information. NOTE: The number of times PTT-OFF is sent during a PTT-ON to PTT-OFF

transition is defined by the optional SDP attribute parameter “ptt_rep” negotiated during the SIP session establishment procedure. ptt_rep <PTT OFF Repetition> is the number of PTT OFF messages (0-3) (default value is 0 -> only one PTT OFF message. Refer to 3.6.1.8 for further details

When a VCS endpoint does not have PTT activated and is therefore not sending RTP audio packets, it SHALL send R2S-KeepAlive packets with RTP Header Extension set to ptt-type=PTT OFF and PT=123 towards the GRS Transceiver/Transmitter endpoint at least every R2S-KeepalivePeriod (i.e. default value 200ms). In case of separated GRS Transmitter and Receiver, the VCS endpoint SHALL send RTP packets towards the Receiver with the RTP Header Extension set to the same ptt_type value sent towards the Transmitter (see Figure 15). In order to reduce the bandwidth usage, the VCS endpoint SHOULD use R2S packet (PT=123) on every R2S-KeepalivePeriod. As a GRS Transceiver/Transmitter endpoint SHALL be able to detect PTT ON/OFF state, the use of Voice Activity Detection SHALL NOT be used on the RTP session established between the VCS and GRS endpoints. Sending PTT OFF and PT=8 in RTP packets every 20ms continuously SHOULD NOT be used.

5.5.3 GRS Transceiver/Receiver Squelch activation/ de-activation

10 [RTP] RTP Radio Squelch activation/de activation Squelch information is conveyed within the RTP header extension of the RTP packet sent from the GRS Transceiver/Receiver endpoint to the VCS endpoint. When Squelch is not active, the RTP packet SHALL include the SQUELCH-OFF information in the RTP header extension of the RTP packets. From this point onwards the link between the VCS endpoint and the GRS Transceiver/Receiver endpoint SHALL be monitored by exchanging either R2S KeepAlive packets (preferred solution) or RTP audio packets. The R2S KeepAlive packets SHALL be sent at least with the R2S-Keepalive period (i.e. default 200ms). When RTP audio packets are used for link monitoring, then the RTP packets SHALL include the SQUELCH-OFF information in the RTP header extension and the RTP payload MAY include audio samples. When Squelch is active, the RTP packet SHALL include the SQUELCH-ON information in the RTP header extension of the RTP packet and the RTP payload SHOULD include audio samples. In the case that the A/C call is active and new radio signalling information or the radio remote control information is transported via the RTP HE of an R2S packet from the VCS endpoint to GRS Transceiver/Receiver endpoint, the VCS endpoint SHALL send an R2S-Keepalive packet within the maximum command delay and the GRS Transceiver/Receiver endpoint SHALL acknowledge information in the RTP HE of the next RTP packet sent to the VCS endpoint.

© EUROCAE, 2012

48

An example of a Squelch ON/OFF reception timing-diagram is shown in Figure 9 below:

FIGURE 9: RECEPTION TIMING DIAGRAM

5.5.3.1 GRS Transceiver/receiver Squelch de-activation event

In order to improve the detection of Squelch deactivation event, RTP packets with a RTP header extension defining Squelch deactivation SHOULD be repeated a number of times (e.g. 3 times, i.e. ptt_rep:2) in a short period in order to guarantee that the reception is switched off. From this point onwards R2S KeepAlive packets with a RTP header extension SHALL be sent with at least the R2S-Keepalive period (i.e. default 200ms). In the case however that the Squelch is deactivated and new radio signalling information or the radio remote control information is transported via the RTP HE of an R2S-Keepalive packet, the VCS endpoint SHALL send an R2S-Keepalive packet within the maximum command delay and the GRS Transceiver/Receiver endpoint SHALL respond with a R2S-Keepalive packet within the maximum confirmation delay. NOTE: The command delay is introduced in order to give the ANSPs the

possibility to define a value for this delay and to test this value. From the functional point, the VCS endpoint shall immediately send a PTT-OFF event with the corresponding R2S packet, as described above. The command delay is defined as the time when the VCS endpoint receiving an event on an internal interface and sending the corresponding command on the IP interface in the RTPTx direction

© EUROCAE, 2012

49


5.5.3.2 Receive Path RTP audio to R2S-Keepalive packet transition

When a GRS Transceiver/Receiver endpoint detects an incoming RF signal at the antenna it activates the SQUELCH signal and SHALL send an RTP audio packet with RTP Header Extension set to SQL ON and PT=Codec Number type (i.e. PT=8 for G.711 codec) towards the VCS endpoint every RTP audio packet period (i.e. default value 20ms). When a GRS Transceiver/Receiver endpoint no longer detects an incoming RF signal it deactivates the SQUELCH signal and SHALL send at least one RTP audio packet with RTP Header Extension set to SQL OFF and PT=Codec Number type (i.e. PT=8 for G.711 codec) towards the VCS endpoint. The optional SDP attribute – “ptt_rep” defines how many additional RTP audio packets SHALL forward the SQL OFF information towards the VCS endpoint. Afterwards the SQL OFF information will be sent by R2S packets, at least once every R2S-KeepalivePeriod. If an RF signal appears in the meantime, the GRS Transceiver/Receiver endpoint SHALL send an RTP audio packet with SQL ON information. When a GRS Transceiver/Receiver endpoint has signal deactivated it SHALL send either R2S-KeepAlive packets or RTP audio packets with the SQU bit in the RTP Header Extension set to SQL OFF and the corresponding payload type PT (PT=123 for R2S-KeepAlive packets or PT=Codec Number type for RTP audio packets) towards the VCS endpoint. The R2S KeepAlive packets SHALL be sent at least every R2S-KeepalivePeriod (i.e. default value 200ms).

5.5.4 RTP Header Extension description

11 [RTP] RTP Header Extension description The RTP header extension is used to transmit additional information necessary for radio communication. (I.e. PTT activation info, Squelch indication, signal quality index, etc.). The extension SHALL be implemented according to RFC 3550 [21] and is described as follows: The X bit in the RTP header SHALL be set to one which causes a variable-length RTP header extension to be appended to the RTP header, following the CSRC list if present. The RTP header extension contains a 16-bit Length field that indicates the number of 32-bit words in the extension, excluding the four-octet header extension. In order to allow multiple inter-operating implementations to experiment independently with different RTP header extensions, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. (Refer to Figure 10).

© EUROCAE, 2012

50

FIGURE 10: RTP HEADER EXTENSION

The Type field should identify the header extension format specific to the application. The first byte of the Type field (bit 0 to bit 7) specifies the Version of the RTP HE and the second byte (bit 8 to bit 15) determines that the RTP HE is defined in the EUROCAE WG67. The RTP HE Version SHALL be set to 1 and therefore the Type field SHALL be set to 0x0167h. NOTE: The Type field of the RTP HE defined in the ED-137 Version 1.0 (February

2009) is set to 0x0067h. The RTP Header extension version shall be negotiated with the SDP parameter "a=rtphe"

The possibility of defining additional RTP header extension types is left open for the future. It would then be necessary to maintain a list of all RTP header extension types together with the format of the extension itself in order to allow interoperability between different applications with these new header extension formats. This scope of using a RTP header extension is to transport all real-time radio signalling between the VCS and GRS endpoints. The contents of the RTP header extension is different for the transmit path from a VCS endpoint towards a GRS Transceiver/Transmitter endpoint and the receive path from a GRS Transceiver/Receiver endpoint towards a VCS endpoint. The Real time Transport Protocol Header Extension (RTP-HE) SHALL be employed to transport, among others, the following signalling information in real time between User Agents at the VCS and GRS endpoints: From the VCS to GRS endpoints; a) PTT (Push To Talk) b) PTT Identity c) PTT Mute information d) PTT Summation e) Climax Time Delay value (used for CLIMAX application) From the GRS to VCS endpoints; a) Squelch (SQL); b) Quality index (used for the Best Signal Signalling feature) c) Stepped-on (Simultaneous) transmission indication d) PTT Confirmation e) PTT Summation

© EUROCAE, 2012

51

The radio signalling information to be transported between VCS and GRS (i.e. Transceiver, Transmitter and Receiver) endpoints SHALL be defined in the RTP header extension of both RTP audio packets and R2S-Keepalive packets. (Refer to Figure 11). The transmit path RTP-HE (RTPTx) and receive path RTP-HE (RTPRx) between the VCS endpoint and separated GRS Transmitter and Receiver entities is shown in Figure 11 below.

NETWORKENTITY(VCS)

RX

TX

interface

RTPTx

RTPRxRTPTx

RTPRx

TxIF

RxIF

FIGURE 11: BASIC RADIO SYSTEM TOPOLOGY

As shown in Figure 11 two different types of interfaces exist: • TxIF: Interface between a ground entity (e.g. a VCS endpoint) and a GRS

transmitter endpoint. • RxIF: Interface between a ground entity (e.g. a VCS endpoint) and a GRS

receiver endpoint. Therefore the following RTP Header Extensions will be defined: • RTPTx: RTP Header Extension for real time signalling from a VCS endpoint to a

GRS transceiver, transmitter or receiver endpoint: Two cases shall be taken in account

i. RTPTx including audio packets ii. RTPTx without audio packet during Keep Alive message (see 0)

• RTPRx: RTP Header Extension for real time signalling from the GRS transceiver, transmitter or receiver endpoint to a VCS endpoint Two cases shall be taken in account

i. RTPRx including audio packets ii. RTPRx without audio packet during Keep Alive message (See 0)

The total length of the transported information is confined to a 32 bit boundary. The 32 bit block is divided into a sub-block with fixed information and a sub-block with variable information. The first sub-block contains mandatory information that SHALL be sent in each RTP packet. The second sub-block is used for mandatory information that is not sent in each RTP packet or for optional information that can be used by additional features. The first 16 bits (Bits 0-15) of the RTPTx/RTPRx header extension is the fixed sub-block and SHALL cover all standard applications. All bits that are not used or reserved SHALL be set to zero. If it is necessary to send additional information which doesn’t fit into this 32 bit block, the RTP Header extension SHALL be extended with another 32 bits. For that reason a GRS endpoint and a VCS endpoint SHALL support serialisation of multiple Extensions within one RTPTx/Rx HE signalling.

© EUROCAE, 2012

52

5.5.5 RTPTx Information field

12 [RTP] RTPTx Information field Figure 12 below shows the RTPTx Information field carried within the header extension of a RTP stream towards a GRS transceiver, transmitter or receiver endpoint (extension type and length field are not shown).

FIGURE 12: RTPTX INFORMATION FIELD

The present definition of the RTP header extension defined by this document however already ensures support for typical ATC radio services as used in existing standard applications. • PTT-type (3 bits: b0 to b2)): This field defines the PTT type sent by the VCS

endpoint towards the GRS Transceiver/Transmitter endpoint in order to activate transmission over the air.

Besides Normal PTT-ON, three other PTT types are defined and are used to support additional services, e.g. Coupling, Priority, and Emergency PTT.

The possible ptt-type values are indicated in below: Table 12 In the case of a single SIP session with the GRS transceiver/transmitter

endpoint, the same ptt-type value sent in the RTPTx HE SHALL be echoed back towards the VCS endpoint in the RTPRx HE. If the GRS is not able to execute the PTT, i.e. to transmit for some reason (e.g. detected errors in the radio, PTT time-out) the GRS SHALL send ptt-type value PTT OFF.

In the case of a multiple SIP sessions established with a GRS transceiver/transmitter endpoint, the ptt-type value sent in the RTPTx HE MAY NOT be that echoed back towards the VCS endpoint in the RTPRx HE. If the GRS is not able to execute the PTT, i.e. to transmit for some reason (e.g. detected errors in the radio, PTT time-out) the GRS SHALL send ptt-type value PTT OFF. If the sent and received ptt-type values are different this implies that a different VCS endpoint with a higher ptt-type is activating transmission at the Transceiver/Transmitter or the radio is not able to execute the PTT-request.

PTT value Description 0x00 PTT OFF

0x01 Normal PTT ON

0x02 Coupling PTT ON

0x03 Priority PTT ON

0x04 Emergency PTT ON

0x05 Reserved

0x06 Reserved

0x07 Reserved

TABLE 12 – PTT VALUE LIST

o PTT OFF: When PTT is deactivated, the RTPTx HE will define an explicit PTT-OFF event to be sent in all RTP packets towards the GRS Transceiver/Transmitter endpoint while PTT remains deactivated.

© EUROCAE, 2012

53

o Normal PTT: When PTT is activated, the RTPTx HE will define an explicit Normal PTT-ON event to be sent in all RTP packets towards the GRS Transceiver/Transmitter endpoint while PTT remains activated. This is a standard PTT event.

o Coupling PTT: sent by a VCS endpoint in the RTPTx HE to all GRS Transceivers/Transmitters defined in a cross-coupling group at VCS endpoint. Receiving an incoming aircraft call on any cross-coupled group frequency will cause the VCS endpoint to re-direct RTP audio stream and send coupling-PTT indication towards each GRS endpoint in the group. In this way the GRS Transceiver/Transmitter receiving a coupling-PTT indication understands that audio stream is from another aircraft and not from the controller.

o Priority PTT: When PTT is activated, the RTPTx HE will define an explicit Priority PTT-ON event to be sent in all RTP packets towards the GRS Transceiver/Transmitter endpoint while PTT remains activated. This ptt-type may be sent by a user (i.e. Supervisor) with permission to override ongoing transmissions using a Normal ptt-type.

o Emergency PTT: When PTT is activated, the RTPTx HE will define an explicit Emergency PTT-ON event to be sent in all RTP packets towards the GRS Transceiver/Transmitter endpoint while PTT remains activated. This ptt-type may be sent by a user with permission to override ongoing transmissions using a Normal or Priority ptt-types. This ptt-type has the highest priority is never interrupted by another ptt-type.

• SQU (1bit: b3): This field is not used in the RTPTx HE. It SHALL be set to 0 • PTT-id (6 bits: b4-b9): This field is used by the VCS endpoint to send its PTT-

id previously assigned to it by the GRS receiver, transceiver or transmitter endpoint during the SIP session establishment. This PTT-id SHALL be assigned by the GRS Receiver, Transceiver or Transmitter endpoint to the VCS endpoint using an SDP attribute sent in a 200 OK response during SIP session establishment. The PTT-id shall have a value in the range of 1 to the maximum allowed number of SIP sessions. As a PTT-id value is always assigned by the GRS endpoint, the case when a PTT-id=0 is sent by the VCS endpoint to the GRS endpoint in the RTPTx HE SHOULD NOT occur. An assigned PTT-id value SHALL be included within the RTPTx HE of R2S-Keepalive packets being sent by the VCS endpoint towards the Radio Tx and Radio Rx endpoints or towards the Radio Remote Control Equipment.

• PM (1 bit: b10) – PTT Mute: This field is used for signalling PTT_ON to non-transmitting (not selected) transmitters in a coverage group. If this bit is set to 1 and the GRS Transmitter/Transceiver has chosen this R2S stream for transmitting, then the GRS Transmitter/Transceiver SHALL NOT activate transmission over the air independent of the PTT-type value. This ensures that all transmitters within the coverage group perform PTT arbitration and are locked against other transmissions.

NOTE: The PTT Mute flag is necessary in a multi-site transmitter frequency, that means e.g. 2 transmitters Tx1 and Tx2 of the same frequency are located in different sites – (without any offset). In that case only one transmitter is allowed to transmit, but if different VCS can connect via a network to the radios, it is possible that one VCS connects to Tx1 and the other to Tx2. This can result in a collision, which cannot be avoided by the transmitters. Therefore each VCS has to connect to both transmitters, the active and the passive one and every time when PTT is activated, the VCS send its PTT signalling info to both transmitters (audio only to the active one). In that case both transmitters know about the transmission. Since the passive transmitter shall not transmit the PTT mute flag shall be set to inform this transmitter only about the PTT signalling info and the PTT-ID

© EUROCAE, 2012

54

• PTTS (1bit: b11) – PTT Summation: This field is used by the VCS endpoint to indicate a PTT summation of multiple RTP audio streams in the VCS, e.g. if the corresponding radio interface in the VCS is configured for PTT summation and two users of this VCS are pressing PTT simultaneously. (PTTS = 1, PTT-type = PTT_ON, PTT-id = 1 - PTT_id_max)

• Reserved (3 bits b12-b14): These three bits are reserved for future extensions in the fixed sub-block of the RTPTx HE.

• X (1 bit: b15): This field indicates a marker bit, that SHALL be set to 1 if extended information for additional features are used.

• Extension for Additional Features: The information in the additional feature block is coded in the Type-Length-Value (TLV) format. For backward compatibility, it SHALL be mandatory to set the proper values within the fixed part even if there is redundant information within the additional feature content. When the Extension field is not used, all bits SHALL be set to 0. o Type (4 bits): The Type field is used to identify the feature content within

the session setup being supported by each entity. o Length (4 bits): The Length field defines the length of the Value field in

bytes. Value (variable length): This block: delivers information about the additional features. Figure 13 shows an example of how the information is coded within the additional feature block.

FIGURE 13: PARTITIONING OF THE EXTENSION FOR ADDITIONAL FEATURES

In the RTPTx HE the extension for additional features SHALL be used to transport the “Climax-Time delay” values as well as the Radio Remote Control information and any other Additional Features Types that may be defined in the future. For further information refer to paragraph 5.6.3.

5.5.6 Multiple RTP audio stream management at GRS Transceiver/Transmitter

The behaviour of the GRS Transceiver/Transmitter endpoint with multiple SIP sessions and R2S protocol connections established with VCS endpoints when receiving ptt-types from two RTP communications with associated audio streams SHALL be the following: 1. Receiving two audio RTP streams with the same ptt-type, e.g. “Normal PTT”:

In this case the behaviour of the GRS Transceiver/Transmitter depends on whether “PTT lockout” or “PTT summation” is configured at the GRS Transceiver/Transmitter. In the first case only the first RTP audio stream SHALL be transmitted while in the second case the sum of both RTP audio streams SHALL be transmitted.

© EUROCAE, 2012

55

2. Receiving an audio RTP stream with the ptt type set to “Normal PTT”, “Priority PTT” or “Emergency PTT” while another RTP stream with ptt type set to “Coupling PTT”, is already being transmitted: then the behaviour depends on whether “Coupling PTT interruption” or “Coupling PTT summation” is configured at the GRS Transceiver/Transmitter. In the first case the RTP audio stream with “Coupling PTT” SHALL be interrupted and only the second RTP stream SHALL be transmitted, while in the second case the sum of both RTP audio streams SHALL be transmitted.

3. Receiving an audio RTP stream with the ptt type set to “Normal PTT”, while another RTP stream with ptt type set to “Priority PTT” or “Emergency PTT” is already being transmitted: then its transmission SHALL continue and the newly received audio steam SHALL be blocked.

4. Receiving one audio RTP stream with “Priority PTT”, while another RTP stream is already being transmitted: If the audio stream already being transmitted has the ptt type set as “Normal PTT”, its transmission SHALL be interrupted and only the new RTP stream with “Priority PTT” SHALL be sent. If the audio stream already being transmitted has the ptt type set as “Emergency PTT”, its transmission SHALL continue and the newly received audio RTP stream SHALL be blocked. Otherwise rule 1 or rule 2 become effective.

5. Receiving one audio RTP stream with “Emergency PTT”, while another RTP stream is already being transmitted: If the audio stream already being transmitted has the ptt type set as “Normal PTT” or “Priority PTT” , its transmission SHALL be interrupted and only the new RTP stream SHALL be sent. Otherwise rule 1 or rule 2 become effective.

5.5.7 RTPRx Information field

13 [RTP] RTPRx Information field Figure 14 below shows the RTPRx information field carried within the header extension of a RTP stream from a GRS Transceiver, Transmitter or Receiver endpoint (extension type and length field are not shown).

FIGURE 14: RTPRX INFORMATION FIELD

To ensure that the RTP header ends at a 32 bit boundary, the minimum possible extension is 4 Bytes, where bits 0 to bit 15 are split into the following protocol fields: • PTT-type (3 bits: b0 to b2): This field SHALL contain the PTT type being used

by the GRS Transceiver/Transmitter endpoint to activate transmission. The possible ptt-type values are identical to those defined for the RTPTx direction. (See Table 12 of section 0). In case of an Aircraft Call (A/C call) reception, the ptt-type value sent in the RTPRx HE SHALL be set to PTT OFF. If this field is not used, it SHALL be set to 0. In the case of only a single SIP session with the GRS Transceiver/Transmitter endpoint, the ptt-type value echoed back towards the VCS endpoint in the RTPRx HE SHALL be the same as that sent in the RTPTx HE by the VCS endpoint.

© EUROCAE, 2012

56

In the case of a multiple SIP sessions established with a GRS Transceiver/Transmitter endpoint, the ptt-type value echoed back towards the VCS endpoint in the RTPRx HE MAY NOT be the same as that sent in the RTPTx HE by the VCS endpoint. This field SHALL contain the PTT type being used by the GRS Transceiver/Transmitter endpoint to activate transmission. If the sent and received ptt-type values are different this implies that a different VCS endpoint with a higher ptt-type is activating transmission at the GRS Transceiver/Transmitter. In case of an Aircraft Call (A/C call) reception, the ptt-type value sent in the RTPRx HE SHALL be set to PTT OFF.”

• SQU (1 bit: b3): This field SHALL contain the Squelch indication from the GRS Transceiver/Receiver. This field SHALL be used to indicate Squelch activity to the VCS endpoints. The possible values are defined in Table 14 below.

SQU Description

0x00 SQ OFF

0x01 SQ ON

TABLE 13 – SQUELCH INFORMATION BIT

• PTT-id (6 bits: b4-b9): This field is used by the GRS Receiver, Transceiver or Transmitter endpoint to indicate the PTT-id of the VCS endpoint that currently has transmission activated. This PTT-id SHALL be assigned by the GRS Receiver, Transceiver or Transmitter endpoint to the VCS endpoint using an SDP attribute sent in a 200 OK response during SIP session establishment. The PTT-id shall have a value in the range of 1 to the maximum allowed number of SIP sessions. In the case of PTT summation of multiple RTP audio streams at the GRS Transceiver/Transmitter, SHALL echo back the PTT-id value to each VCS endpoint which transmitting. In addition the PTTS bit SHALL be set to 1 in order to indicate PTT summation. As a PTT-id value is always assigned by the GRS endpoint, the case when a PTT-id=0 is sent by the VCS endpoint to the GRS endpoint in an RTPTx HE SHOULD NOT occur.

In the case of a single SIP session with the GRS transceiver/transmitter endpoint, the PTT-id value echoed back towards the VCS endpoint in the RTPRx HE SHALL be the same as that sent in the RTPTx HE by the VCS endpoint. A PTT-id value SHALL be included within the RTPRx HE of R2S-Keepalive packets being sent by the Radio Tx, Radio Rx endpoints or Radio Remote Control Equipment (RRCE) towards VCS endpoints.

In the case of an incoming Aircraft Call at a GRS Receiver the PTT-id field in the RTPRx HE SHALL be set to 0.

NOTE: When the same PTT-id value is echoed back together with the corresponding PTT-type value then this is a confirmation that the user is transmitting -> PTT Confirmation (see Figure 15). If the same PTT-type is echoed back with a different PTT-id value, this implies that PTT lock-out is configured at the GRS Transceiver/Transmitter endpoint and another user is transmitting.

© EUROCAE, 2012

57

FIGURE 15: PTT CONFIRMATION FOR SEPARATED GRS (A) AND COMBINED GRS (B)

• PM (1 bit: b10) – PTT Mute: This field is used for signalling PTT_ON to non-transmitting transmitters in a coverage group. A GRS endpoint SHALL sent back the PTT Mute flag, from those RTP/R2S stream which was selected for transmitting, t to all users connected to the GRS endpoint in the RTPRx HE.

NOTE: PTT Mute Example: 2 transmitters Tx1 and Tx2 of the same frequency are located in different sites – (without any offset). Two users, User 1 (PTT-Id 1) would like to use Tx1 for transmission and User 2 (PTT-Id 2) would like to use Tx2 for transmission. Both users would like to transmit at the same time, whereby User 2 using Priority PTT and User 1 only Normal PTT. The following values shall be sent to Tx1 from the different users in the RTPTx direction: User 1 sends: PTT type = Normal PTT; PTT-ID 1; PM=0 User 2 sends: PTT type = Priority PTT; PTT-ID 2; PM=1 The following values shall be sent to Tx2 from the different users in the RTPTx direction: User 1 sends: PTT type = Normal PTT; PTT-ID 1; PM=1 User 2 sends: PTT type = Priority PTT; PTT-ID 2; PM=0 The following values shall be sent back to the different users in the RTPRx direction of Tx1: User 1 gets echoed back: PTT type = Priority PTT; PTT-ID 2 + PM=1 User 2 gets echoed back: PTT type = Priority PTT; PTT-ID 2; PM=1 The following values shall be sent back to the different users in the RTPRx direction of Tx2: User 1 gets echoed back: PTT type = Priority PTT; PTT-ID 2 + PM=0 User 2 gets echoed back: PTT type = Priority PTT; PTT-ID 2; PM=0

© EUROCAE, 2012

58

• PTTS (1bit: b11) – PTT Summation: This field is used by the GRS endpoint to indicate a PTT summation of multiple RTP audio streams at a transceiver or transmitter (PTTS = 1, PTT-id = 1 - 7)

NOTE: In the case when PTT summation is configured and a simultaneous transmission occurs (2 RTP streams with the same PTT priority level) the transmitter should send back to all users connected to this transmitter a PTT-ID and the PTTS bit set to one. For example: Simultaneous transmission of User 1 (PTT-Id 1), User 2 (PTT-Id 2) and User 3 (PTT-Id 3): If User 2 and User 3 using Priority PTT and User 1 only Normal PTT then the transmitter will sum the audio of User 2 and User 3 and will block the signal of User 1! The following values shall echoed back to the different users in the RTPRx direction: User 2 gets echoed back: PTT-ID 2 + PTTS=1, User 3 gets echoed back: PTT-ID 3 + PTTS=1, User 1 gets echoed back: PTT-ID 2 + PTTS=1, -> “PTT lock out. If more than one user transmitting always the lowest transmitting PTT-ID will be echoed back to all users which are not transmitting.”

• SCT (1bit: b12) - Simultaneous Call Transmissions: This field is used by the GRS endpoint to indicate to the VCS endpoint when simultaneous transmissions is being detected in real time. The bit SHALL be set to SCT=1, if simultaneous transmissions are detected. The value SHALL be set in each RTP packet as long as the simultaneous transmission lasts. The SCT bit indicates either two simultaneous incoming Aircraft Calls (SCT = 1, PTT-id = 0), or an incoming aircraft call simultaneously with a transmission of a controller. (SCT = 1, PTT_Type= PTT_ON, PTT-id = 1 – PTT_id_max),

• Reserved (2 bits b13-b14): These two bits are reserved for future extensions in the fixed sub-block of the RTPRx HE.

• X (1 bit: b15): This field indicates a marker bit, that SHALL be set to 1 if extended information for additional features are used.

• Extension for Additional Features: The same as in the RTPTx information field (see section 0).

The RTPRx HE the extension for additional features SHALL be used to transport the “Best Signal Selection” quality index and “Best Signal Selection” methods list as well as the Radio Remote Control information and any other Additional Features Types that may be defined in the future.

5.6 ADDITIONAL FEATURES BLOCK

The “Additional Features” block is used for mandatory information that is not sent in each RTP packet or for optional information that can be used by additional features. The information in the additional feature block is coded in the Type-Length-Value (TLV) format. For backward compatibility, it SHALL be mandatory to set the proper values within the fixed part even if there is redundant information within the additional feature content. The following tables (Table 14 and Table 15) list all currently defined mandatory features transported within the Additional Features block in the RTPTx and RTPRx directions. The serialisation of multiple Extensions within one RTPTx/Rx HE SHALL be supported in order to allow the transport e.g. CLIMAX Time Delay and a vendor specific feature within one RTP packet from the VCS endpoint towards the GRS endpoint.

© EUROCAE, 2012

59

The following Types are defined for the RTPTx direction:

Type Description 0x0 No more additional features 0x1 Reserved

0x2 CLIMAX-Time Delay

0x3 Radio Remote Control

0x4 CLIMAX Dynamic Delay Compensation

0x5– 0xA Reserved

0xB – 0xF Reserved for vendor specific usage

TABLE 14 – RTPTX ADDITIONAL FEATURE TYPE DEFINITION

The following Types are defined for the RTPRx direction:

Type Description 0x0 No more additional features

0x1 SQI

0x2 Reserved

0x3 Radio Remote Control

0x4 CLIMAX Dynamic Delay Compensation

0x5 – 0xA Reserved

0xB – 0xF Reserved for vendor specific usage

TABLE 15 – RTPRX ADDITIONAL FEATURE TYPE DEFINITION

The value Type=0 is used if no additional feature is transported via this RTP packet (even if X marker bit =1). The values 0x4 to 0xA are reserved for future additional features that SHALL be standardized for interoperability. The values 0xB to 0xF are reserved for vendor specific functions.

5.6.1 Serialisation of multiple Additional Feature blocks

The GRS and VCS endpoints SHALL support the serialisation of multiple additional feature blocks within one RTPTx or RTPRx HE field. Serialization of multiple Additional Feature Blocks SHALL be accomplished as follows: • Each Additional Feature Block SHALL use between 2 and 16 octets of the

Header Extension Information Fields (RTPTx and RTPRx). • The number of Information Fields used SHALL be reflected by the length of the

RTP HE. If necessary, zero-padding SHALL be used to complete the last 32-bit Header Extension Information Field.

5.6.2 Signal Quality Information

A Signal Quality Information (SQI) for BSS SHALL be included in the RTP HE to handle multi-receiver frequencies. A BSS function (e.g. in the VCS) should take into account the audio signal quality and the relative delay between the incoming signals. In addition, the implementation should support different methods for the determination of the signal quality.

© EUROCAE, 2012

60

Thus the Signal Quality Information transported via the Additional Features block in the RTP Header Extension contains the Signal Quality Index (BSS-qidx) and the Signal Quality Method (BSS-qidx-ML). The Signal Quality Index Feature is only used in the RTPRx direction.

Type Length Value 0x01 1 BSS-qidx and BSS-qidx-ml

TABLE 16 – TLV VALUES FOR SQI

Figure 16 shows the TLV coding for Best Signal Selection.

FIGURE 16: SQI TLV CODING

• Type (4 bit): The Type field for SQI is set to Type = 1 • Length (4 bit): The Length field for SQI is set to Length = 1 • Value (1 Byte): The value of the SQI feature is subdivided into the bss-qidx and

the bss-qidx-ml fields. o BSS-qidx (5 bits: b24 to b28): BSS Quality Index SHOULD deliver

information about the quality of the received signal. The quality value of the received signal is used to determine the Best Signal received (Best Signal Selection: BSS) when several receivers are associated.

The meaning of the Quality Index value indicated in this field depends on the method employed for Best Signal Selection evaluation as defined in the BSS-qidx-ml field.

When no Quality Index value is available from the receiver, the BSS-qidx field SHALL be set to 0 .This value 0x00’ is independent of the BSS-qidx-ml field and denotes that up until now no quality index is available (refer to Table 17 below).

BSS-qidx Description

0x00 No Quality Index available

0x01-0x1F Method specific meaning

TABLE 17 – DEFINITION OF QUALITY INDEX VALUES

© EUROCAE, 2012

61

o BSS-qidx-ml (3 bits: b29 to b31): BSS Quality Index – Methods List. The Table 18 below identifies all standardized methods for evaluating the quality of a received radio signal.

bss-qidx-ml Description M/O

0x0 RSSI M

0x1 AGC Level O

0x2 C/N O

0x3 Standardized PSD O

0x4 - 0x7 Vendor specific methods

TABLE 18 – LIST OF BSS QUALITY INDEX METHODS

The ‘M/O’ column denotes if the method SHALL be mandatory (M) or optional (O). As this information is delivered together with the audio on the receive path, it could occur that some of the methods are not provided with the first RTP packets (e.g. a method takes some processing time). The proprietary vendor specific BSS-qidx-ml (0x4 to 0x7) methods can be negotiated during SIP session establishment through and exchange of SDP attributes. A detailed description of the BSS Quality index methods can be found in ANNEX B of this document. 14 [RTP] RTP BSS quality index method- RSSI The values calculated using the RSSI Best Signal Selection quality index method SHALL conform to the Signal Quality Parameter (SQP) described in the ETSI standard EN 301-841-1. 0 Signal quality analysis SHALL be performed on the demodulator evaluation process and on the receive evaluation process; this analysis SHALL be normalized between a scale of 0 and 15, where 0 represents a received signal strength lower than -100 dBm and 15 for a signal strength higher than -70 dBm. SQP value between -100 dBm and -70 dBm SHALL be linear. The SQP value normalized between 0 and 15 SHALL be coded in the BSS-qidx field as the bits b24 to b28 where b28 is the lower significant bit and b24 the upper significant bit.

5.6.3 CLIMAX-Time Delay

15 [RTP] RTP Climax operation timing In Multi-Carrier/Climax operation the difference between the longest and the shortest voice latencies for ground transmission components SHALL be a maximum of 10ms. The CLIMAX Time Delay feature is used by the VCS endpoint to send a delay value “CLD” in milliseconds to a GRS Transceiver/Transmitter endpoint within the CLD field of the Transmit path RTPTx header extension. On receiving this value the GRS Transceiver/Transmitter endpoint SHALL then delay the voice transmission by CLD ms in order to reduce delay differences below 10ms.

Type Length Value 0x02 1 CLD

TABLE 19 – TLV VALUES FOR CLIMAX TIME DELAY

Figure 17 shows the TLV coding for the CLIMAX Time Delay feature.

© EUROCAE, 2012

62

FIGURE 17: CLIMAX TIME DELAY TLV CODING

• Type (4 bit): The Type field for CLIMAX Time Delay is set to Type = 2 • Length (4 bit): The Length field for CLIMAX Time Delay set to Length = 1 • Value (1 Byte): The CLD value of the CLIMAX Time Delay functionality defines

the time for which the transmitter has to delay the voice. The value SHALL be defined in units of two ms. The most significant bit (b24) is used as discrimination between relative and absolute delay. If the most significant bit is set to 0, the CLD value from b31 to b25 shall be used as relative delay. This means each audio sample SHALL be delayed by the CLD value. If the b24 is set to 1, the CLD value from b31 to b25 shall be used as absolute delay – this means the RTP time value shall be interpreted as absolute time value and the RTP time value + the absolute CLD value defining the time when the audio SHALL be transmitted on air. The range of CLD is between 0ms and 254msThe CLD value evaluated between 0 and 127 SHALL be coded in the CLD field by bits b25 to b31 where b31 is the lower significant bit and b25 the upper significant bit.

5.6.4 Radio Remote Control

The Radio Remote Control (RRC) SHALL be implemented in the Additional Features” block of the RTP HE to handle Main/Standby switchover and to use two frequencies with one SIP session and RTP stream (paired frequency). The content of the RRC information field depends on the configuration of the RRCE. • Paired Frequency: If the RRCE endpoint handles a paired frequency, all bits

and bytes of the RRC SHALL be considered • Single Frequency: If the RRCE handles equipment of a single frequency, only

four bits MSTxF1, MSRxF1, MuRxF1 and SelTxF1 SHALL be considered (see Figure 18). The other bits and bytes of the RRC value field SHALL be ignored.

© EUROCAE, 2012

63

5.6.4.1 RTPTx Definition

FIGURE 18: RRC RTPTX TLV CODING

Figure 18 shows the TLV coding for Radio Remote Control in the RTPTx direction from the VCS endpoint towards the RRCE endpoint. For the RTPTx: • Type (4 bit): The Type field for RRC is set to Type = 3. • Length (4 bit): The Length field for RRC is set to Length = 1 • Value (1 Byte): The RRC RTPTx TLV Value field is divided into 8 flags.

o MSTxF1: This flag is used as signalling mechanisms to select the Main or Standby Transmitter of frequency F1. If the MSTxF1=0, the Main Transmitter of frequency F1 SHALL be used for transmission. If the MSTxF1 = 1, the Standby Transmitter of frequency F1 SHALL be used for transmission. This Flag SHALL be valid in both RRCE configurations.

o MSRxF1: This flag is used as signalling mechanisms to select the Main or Standby Receiver of frequency F1. If the MSRxF1=0, the Main Receiver of frequency F1 SHALL be used. If the MSRxF1 = 1, the Standby Receiver of frequency F1 shall be used. This Flag SHALL be valid in both RRCE configurations.

o MSTxF2: This flag is used as signalling mechanisms to select the Main or Standby Transmitter of frequency F2. If the MSTxF2=0, the Main Transmitter of frequency F2 SHALL be used for transmission. If the MSTxF2 = 1, the Standby Transmitter of frequency F2 SHALL be used for transmission. This Flag SHALL be valid only in the RRCE configuration “Paired Frequency”.

o MSRxF2: This flag is used as signalling mechanisms to select the Main or Standby Receiver of frequency F2. If the MSRxF2=0, the Main Receiver of frequency F2 SHALL be used. If the MSRxF2 = 1, the Standby Receiver of frequency F2 shall be used. This Flag SHALL be valid only in the RRCE configuration “Paired Frequency”.

o SelTxF1: This flag is used as signalling mechanisms to select the active Transmitter of frequency F1 for transmission, if a PTT is activated. If the SelTxF1=0, the active transmitter of frequency F1 SHALL NOT be used in case a PTT is active. If the SelTxF1=1, the active transmitter of frequency F1 SHALL be used for transmission. This Flag SHALL be valid in both RRCE configurations.

© EUROCAE, 2012

64

o SelTxF2: This flag is used as signalling mechanisms to select the active Transmitter of frequency F2 for transmission, if a PTT is activated. If the SelTxF2=0, the active transmitter of frequency F2 SHALL NOT be used in case a PTT is active. If the SelTxF2=1, the active transmitter of frequency F2 SHALL be used for transmission. . This Flag SHALL be valid only in the RRCE configuration “Paired Frequency”.

o MuRxF1: This flag is used as signalling mechanisms to enable a Remote Receiver Muting of frequency F1. If the MuRxF1=0 the audio of the active receiver of frequency F1 (Main or Standby) at the RRCE endpoint SHALL be unmuted. If the MuRxF1=1 the audio of the active receiver of frequency F1 (Main or Standby) at the RRCE endpoint SHALL be muted. This Flag SHALL be valid in both RRCE configurations.

o MuRxF2: This flag is used as signalling mechanisms to enable a Remote Receiver Muting of frequency F2. If the MuRxF2=0 the audio of the active receiver of frequency F2 (Main or Standby) at the RRCE endpoint SHALL be unmuted. If the MuRxF2=1 the audio of the active receiver of frequency F2 (Main or Standby) at the RRCE endpoint SHALL be muted. This Flag SHALL be valid only in the RRCE configuration “Paired Frequency”.

5.6.4.2 RTPRx Definition

5.6.4.2.1 RRCE in the “Paired Frequency” Configuration

In Paired Frequency Configuration, unmuted audio from the two active receivers SHALL be combined internally by the RRCE prior to being forwarded to the VCS in a single RTP packet stream. Figure 19 shows the TLV coding for Radio Remote Control in the RTPRx direction from the RRCE endpoint towards the VCS endpoint in the “Paired Frequency” Configuration.

FIGURE 19: “PAIRED FREQUENCY” RRC RTPRX TLV CODING

© EUROCAE, 2012

65

For the RTPRx in the “Paired Frequency” Configuration: • Type (4 bit): The Type field for RRC is set to Type = 3. • Length (4 bit): The Length field for RRC is set to Length = 4 • Value (4 Bytes):

• First Byte: The RRC RTPRx TLV Value field first byte is subdivided into 8 flags. o MSTxF1: This flag is used to confirm the selection of the Main or

Standby Transmitter of frequency F1. MSTxF1=0 SHALL indicate that the Main Transmitter of frequency F1 has been selected. MSTxF1 = 1 SHALL indicate that the Standby Transmitter of frequency F1 has been selected.

o MSRxF1: This flag is used to confirm the selection of the Main or Standby Receiver of frequency F1. MSRxF1=0 SHALL indicate that the Main Receiver of frequency F1 has been selected. MSRxF1 = 1 SHALL indicate that the Standby Receiver of frequency F1 has been selected.

o MSTxF2: This flag is used to confirm the selection of the Main or Standby Transmitter of frequency F2. MSTxF2=0 SHALL indicate that the Main Transmitter of frequency F2 has been selected. MSTxF2 = 1 SHALL indicate that the Standby Transmitter of frequency F2 has been selected.


o SelTxF1: This flag is used to indicate the keying of the selected F1 transmitter. If PTT is active (RTPRx HE PTT_type field not zero), this bit SHALL be interpreted as confirmation of the status of the active Transmitter of frequency F1 as selected by RTPTx HE SelTxF1 flag. SelTxF1=0 SHALL indicate that the active transmitter of frequency F1 is not being keyed. SelTxF1=1 SHALL indicate that the active transmitter of frequency F1 is being keyed.

o SelTxF2: This flag is used to indicate the keying of the selected F2 transmitter. If PTT is active (RTPRx HE PTT_type field not zero), this bit SHALL be interpreted as confirmation of the status of the active Transmitter of frequency F2 as selected by RTPTx HE SelTxF2 flag. SelTxF2=0 SHALL indicate that the active transmitter of frequency F2 is not being keyed. SelTxF2=1 SHALL indicate that the active transmitter of frequency F2 is being keyed.

o MuRxF1: This flag is used to confirm the selection of the Remote Receiver Muting of frequency F1. MuRxF1=0 SHALL indicate that the audio of the active receiver of frequency F1 (Main or Standby) at the RRCE endpoint is unmuted. MuRxF1=1 SHALL indicate that the audio of the active receiver of frequency F1 (Main or Standby) at the RRCE endpoint is muted.

o MuRxF2: This flag is used to confirm the selection of the Remote Receiver Muting of frequency F2. MuRxF2=0 SHALL indicate that the audio of the active receiver of frequency F2 (Main or Standby) at the RRCE endpoint is unmuted. MuRxF2=1 SHALL indicate that the audio of the active receiver of frequency F2 (Main or Standby) at the RRCE endpoint is muted.

© EUROCAE, 2012

66

• Second Byte: The RRC RTPRx TLV second byte is subdivided into two 1-bit flags and six bits reserved for future use. o SQF1: This flag is used to report the Squelch Break status of the

selected F1 receiver. SQF1=0 SHALL indicate that the Squelch Break of the active receiver of frequency F1 is not active (No RF signal present, no audio from Receiver). SQF1=1 SHALL indicate that the Squelch Break of the active receiver of frequency F1 is active (RF signal present, audio available from Receiver). If the Squelch Break of the active receiver of frequency F1 is active (Squelch Break ON), RTPRx HE SQU field SHALL also be set to one.

o SQF2: This flag is used to report the Squelch Break status of the selected F2 receiver. SQF2=0 SHALL indicate that the Squelch Break of the active receiver of frequency F2 is not active (No RF signal present, no audio from Receiver). SQF2=1 SHALL indicate that the Squelch Break of the active receiver of frequency F2 is active (RF signal present, audio available from Receiver). If the Squelch Break of the active receiver of frequency F2 is active (Squelch Break ON), RTPRx HE SQU field SHALL also be set to one.

• Third Byte: The value of the RRC RTPRx TLV third byte is used to report the Signal Quality Information corresponding to the selected Receiver on frequency F1. This byte SHALL be formatted as described in Section 5.6.2, Signal Quality Information.

• Fourth Byte: The value of the RRC RTPRx TLV fourth byte is used to report the Signal Quality Information corresponding to the selected Receiver on frequency F2. This byte SHALL be formatted as described in Section 5.6.2, Signal Quality Information.

5.6.4.2.2 RRCE in the “Single Frequency” Configuration

In this configuration, Keying Confirmation and Squelch Break information will be derived from the PTT Type and SQU fields of the fixed part of the RTP Header Extension as described in Section 5.5.7. SQI Information will be obtained using the standard SQI Additional Feature Type as defined in Section 5.6.2 Figure 20 shows the TLV coding for Radio Remote Control in the RTPRx direction from the RRCE endpoint towards the VCS endpoint in the “Single Frequency” Configuration.

FIGURE 20: “SINGLE FREQUENCY” RRC RTPRX TLV CODING

© EUROCAE, 2012

67

For the RTPRx in the “Single Frequency” Configuration: • Type (4 bit): The Type field for RRC is set to Type = 3. • Length (4 bit): The Length field for RRC is set to Length = 1 • Value (1 Byte): • The RRC RTPRx TLV Value field byte is subdivided into 4 flags and four

unused bits. o MSTxF1: This flag is used to confirm the selection of the Main or Standby

Transmitter of frequency F1. MSTxF1=0 SHALL indicate that the Main Transmitter of frequency F1 has been selected. MSTxF1 = 1 SHALL indicate that the Standby Transmitter of frequency F1 has been selected.


o MSTxF2: This bit is not used and SHALL be set to zero. o MSRxF2: This bit is not used and SHALL be set to zero. o SelTxF1: This flag is used to indicate the keying of the selected F1

transmitter. If PTT is active (RTPRx HE PTT_type field not zero), this bit SHALL be interpreted as confirmation of the status of the active Transmitter of frequency F1 as selected by RTPTx HE SelTxF1 flag. SelTxF1=0 SHALL indicate that the active transmitter of frequency F1 is not being keyed. SelTxF1=1 SHALL indicate that the active transmitter of frequency F1 is being keyed.

o SelTxF2: This bit is not used and SHALL be set to zero. o MuRxF1: This flag is used to confirm the selection of the Remote

Receiver Muting of frequency F1. MuRxF1=0 SHALL indicate that the audio of the active receiver of frequency F1 (Main or Standby) at the RRCE endpoint is unmuted. MuRxF1=1 SHALL indicate that the audio of the active receiver of frequency F1 (Main or Standby) at the RRCE endpoint is muted.

o MuRxF2: This bit is not used and SHALL be set to zero.

5.6.5 Dynamic Delay Compensation

Dynamic Delay compensation shall be implemented in the Additional Features block of the RTP HE to estimate end to end audio delay between CWP and GRS transmitter or transceiver in order to enable synchronous transmission on all GRS Stations involved in the same climax group The solution is based on estimating the dynamic one-way network delay between the VCS and the GRS. If absolute time is available the one-way delay can be measured directly. If only relative time values are available, then an estimation based on round trip delay measurement is used. In order to get an accurate one way network delay, the VCS endpoint transmits in regular intervals a Request for Measurement Message (RMM) to all GRS transmitter endpoints of a CLIMAX coverage group. The GRS transmitter endpoints answer with a Measurement Answer Message (MAM) to the VCS endpoint, where all relevant information is included. After received the MAM from all GRS endpoints, the VCS endpoint can estimate all end-to-end one-way delays (microphone to antennas) and is able to compensate the audio delay within a CLIMAX group. The audio delay compensation can be done either by initiate additional audio delay or by sending CLD information to the corresponding GRS endpoints. Additional information can be found in ANNEX F.

© EUROCAE, 2012

68

Request for Measurement Message (RMM) The following supplementary information shall be sent by using the additional feature block of the RTP Header Extension from the VCS to the GRS: • TQV (1bit): TimeQualityVCS

- 0: Not Synchronized – No absolute time value available - 1: Synchronized - Absolute time value with the required accuracy

available • T1 (23bit): T1 is the packets transmit time at the VCS endpoint based on 125

µs. ticks. In case that an absolute time value shall be transmitted, the lower 42 bits of the NTP time value shall be converted to a value based on 125 µs. ticks.

NOTE: The NTP timestamp format defines the usage of 64 bit as follows. The first 32 bits are used for the absolute time in seconds starting on 1 January 1900 at 00:00:00. The second 32 bits enable an increase in the resolution by fractions of 1 second. The 32 bits enable a resolution of 233 pico seconds.

Feature type RMM for RTPTx direction is defined as:

Type Length Value 0x04 3 TQV: 1 bit

T1: 23 bits

TABLE 20 – TLV VALUES FOR RMM FOR RTPTX DIRECTION

Response Message from GRS to VCS (MAM) The following supplementary information shall be sent by using the additional feature block of the RTP Header Extension from the GRS to the VCS: • TQG (1bit): TimeQualityGRS

- 0: Not Synchronized – No absolute time value available - 1: Synchronized - Absolute time value with the required accuracy

available • T1 (23bit): Packet transmit time at the VCS endpoint based on 125 µs. ticks. In

case that an absolute time value shall be transmitted, the lower 42 bits of the NTP time value shall be converted to a value based on 125 µs. ticks

• NMR (1bit): New Measurement requested - 0: No request - 1: GRS requests a new RTT measurement, e.g. because of a jitter buffer

under run • T2 (23bit): Packet reception time at the GRS endpoint based on 125 µs. ticks. In

case that an absolute time value shall be transmitted, the lower 42 bits of the NTP time value shall be converted to a value based on 125 µs. ticks.

• Tsd (16 bit): T3 – T2 based on 125 µs. ticks • Tj1 (16bit): Jitter buffer delay based on 125 µs. ticks • Tid (16 bit) – GRS Internal Delay: Represents the internal delay of audio from

the jitter buffer output to the antenna. This value is defined in 125 µs. ticks. Feature type MAM for RTPRx direction is defined as:

© EUROCAE, 2012

69

Type Length Value 0x04 12 TQG: 1 bit

T1: 23 bits NMR: 1 bit T2: 23 bits Tsd: 16 bits Tj1: 16 bits Tid: 16 bits

TABLE 21 – TLV VALUES FOR RMM FOR RTPTX DIRECTION

© EUROCAE, 2012

70

CHAPTER 6

REAL TIME SESSION SUPERVISION

6.1 INTRODUCTION

The SIP provides no inherent mechanism for monitoring the status of the network link. Without a monitoring mechanism one session endpoint which is not receiving any packet will not be able to distinguish between the case when there are no RTP packets sent by the remote endpoint and the case when RTP packets are sent by the remote endpoint, but are lost along the way as they are transported through the network. The Real Time Session Supervision (R2S) connection SHALL be established between two end-points using the Real-time Transport Protocol (RTP) following establishment of the SIP session between the two endpoints. The Real-time Session Supervision is therefore considered an addition to every established SIP session in order to provide an endpoint the awareness about the reachability of its peer endpoint. Two way Real Time Session Supervision connections SHALL therefore be made between the following entities: Á a VCS endpoint and a GRS Transceiver endpoint Á a VCS endpoint and a GRS Transmitter endpoint Á a VCS endpoint and a GRS Receiver endpoint The monitoring mechanism employed by the Real Time Session Supervision uses a periodic exchange of R2S-Keepalive packets between the two endpoints. It is capable of detecting a link loss in the case that R2S-Keepalive packets or RTP Audio packets are not being received. Signalling exchanges employed by the R2S protocol between the endpoints are contained in the RTP Header and the RTP Header extension (especially defined for Radio Signalling). RTP packets used by the Real Time Supervision are nominated R2S-Keepalive packets and these use the same RTP header and RTP header extension as the RTP packets used to transport audio. From a network point of view the two types of RTP packet (i.e. Audio and Keep-alive) are therefore indistinguishable from one another. In addition to the link monitoring capability afforded by the R2S-KeepAlive packet exchange mechanism, the same exchange SHALL be used to send commands and receive confirmation signals when no voice traffic is present. The Real Time Session Supervision has a special Payload Type defined in the RTP header in order to identify R2S-Keepalive packets.

6.2 R2S RADIO SIGNALLING MESSAGE TYPES

The two-way RTP communication made between two endpoints will comprise the following packets: Á RTP audio packets sent every packet-size “interval” (i.e. 20ms default) to the

corresponding endpoint when audio is being transported. Á R2S-Keepalive packets sent at least every R2S-KeepAlivePeriod (i.e. 200ms

default) to the corresponding endpoint when audio is not being transported. Á R2S-Keepalive packets are sent within the maximum command delay when the

VCS endpoint issues a Radio Remote Control command or when a radio signalling information changes and no audio is being transported. The GRS endpoint SHALL respond within the maximum confirmation delay upon the arrival of an R2S or RTP packet containing a Radio Remote Control command or new radio signalling information received from the VCS endpoint with the transmission to the VCS of an R2S or RTP packet as required.”

© EUROCAE, 2012

71

NOTE: The command delay is introduced in order to give the ANSPs the possibility to define a value for this delay and to test this value. From the functional point, the VCS endpoint shall immediately send a PTT-OFF event with the corresponding R2S packet, as described above. The command delay is defined as the time when the VCS endpoint receiving an event on an internal interface and sending the corresponding command on the IP interface in the RTPTx direction


R2S-Keepalive packets and RTP Audio Packets SHALL be sent as one RTP stream. Both R2S-Keepalive packets and RTP Audio Packets SHALL have a RTP header plus the RTP header extension defined for signalling between VCS and GRS endpoints. The content of the RTP header extension SHALL be the same for both RTP Keep-alive and Audio packets.

6.3 R2S SDP ATTRIBUTES

Two SDP attributes relating to the Real Time Session Supervision SHALL be defined through SDP negotiation during SIP session establishment. These are defined as below: - R2S-KeepalivePeriod, - R2S-KeepaliveMultiplier, R2S-KeepalivePeriod: this value expressed in milliseconds is the nominal period between R2S-Keepalive packets that are only sent when there is no voice to be transported R2S-KeepAlive Multiplier: this value, when multiplied by the R2S-KeepAlivePeriod, is used to calculate the R2S-LocalHoldTime The R2S-LocalHoldTime is the time an endpoint will wait to receive RTP packets before disconnecting the RTP communication and clearing the established SIP session between the endpoints. The initial value for the R2S-LocalHoldTime counter (2 seconds default) at SIP session start-up is equal to the value of R2S-KeepalivePeriod multiplied with the value of R2S-KeepaliveMultiplier

FIGURE 21: RTP-AUDIO AND R2S-KEEP ALIVE PACKETS

© EUROCAE, 2012

72

6.4 R2S OPERATION

16 [RTP] Keepalive messages The Real Time Session Supervision SHALL be employed between VCS endpoints and GRS endpoints. Due to mandatory use of the Real Time Session Supervision between the User Agent at the VCS endpoint and the User Agent at the GRS Transceiver, Transmitter or Receiver endpoint, an INVITE request sent from a User Agent at the VCS endpoint to a User Agent at the GRS endpoint SHALL include a <send-receive mode> SDP attribute set to “sendrecv”. This allows a two-way RTP communication to be established with a GRS Transceiver, Transmitter or Receiver endpoint. Following SIP session establishment between VCS and GRS endpoints, the VCS endpoint SHALL send the first R2S-Keepalive packet after sending the SIP ACK message namely within one KeepalivePeriod after the SIP ACK message. The GRS endpoint SHALL send the first R2S-Keepalive packet after sending the SIP 200OK message namely within one KeepalivePeriod after the SIP 200OK message. The VCS or GRS endpoint SHALL therefore only disconnect a SIP session in the case of no R2S-Keepalive packets or RTP Audio packets arriving within the R2S-LocalHoldTime period and this event SHALL be triggered by the R2S-LocalHoldTime counter at the endpoint reaching zero. When a RTP packet or R2S packet is received by an endpoint, it SHALL reset its R2S-LocalHoldTime counter (i.e. default 2 seconds).

6.5 RTP HEADER STRUCTURE FOR R2S-KEEPALIVE PACKETS

An R2S-Keepalive packet is a RTP packet used to transport signalling and not audio. The RTP header extension it employs is defined in chapter 5.5 and the RTP header has the following specification. X=1 PT=123 (dynamic) No RTCP reports are issued for this type of payload. There is an exception when PT will not have the value of 123 but instead will indicate the codec associated to the voice samples. See “Signalling Operations” chapter. CC=0 Sequence number The sequence number increments by one for each RTP data packet sent, and MAY be used by the receiver to detect missing/out-of-sequence packets. Timestamp = A VCS or GRS endpoint SHALL employ an incrementing timestamp value equivalent to the number of voice sample in the time period. This incrementing timestamp value SHALL be maintained in the transition from RTP audio to R2S-Keepalive packet and vice versa. For a G.711 codec for example the timestamps with voice should be equal to the number of samples per voice packet (i.e. 160)- Samples=Packet Duration/Sampling rate =20ms/0.125ms (G.711 codec) =160 voice samples. The Timestamps in R2S-keepalive packets SHALL be increased by the equivalent number of samples between this R2S-keepalive packet and the previous RTP packet (R2S packet or RTP packet with voice). Samples=Time difference to the previous packet/Sampling rate. If, e.g., the time period for Keepalive R2S packets is 200ms the timestamp SHALL be incremented by the number of Samples = 200ms/0.125ms voice samples = 1600 If an R2S packet is sent 40ms after the previous R2S packet because of an RRC command to the GRS, the timestamp shall be increased by 40/0,125 = 320 samples.

© EUROCAE, 2012

73

SSRC identifier: The SSRC identifier of the R2S packets SHOULD be different to the SSRC identifier of the corresponding Voice packets. The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session. The IP addresses and the transport address are exactly the same as for the RTP voice packet ensuring for the signalling message and for the voice packets the same qualification level when transiting the network. Type = 0x0167h. The Type field identifies the header extension format specific to the Radio application

© EUROCAE, 2012

74

ANNEX A

REFERENCES

[1] ETSI standard EN 301-841-1 [2] IETF RFC 768: User Datagram Protocol (UDP), August 1980. [3] IETF RFC 791: Internet Protocol” (IP) version 4, September 1981. [4] IETF RFC 793: Transmission Control Protocol (TCP), September 1981. [5] IETF RFC2104: HMAC: Keyed-Hashing for Message Authentication, February

1997. [6] IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels,

BCP 14, March 1997. [7] IETF RFC 2327: SDP: Session Description Protocol, April 1998. [8] IETF RFC 2460: Internet Protocol, Version 6 (IPv6) Specification, December

1998. [9] IETF RFC 2474: Definition of the Differentiated Services Field (DS Field) in the

IPv4 and IPv6 Headers, December 1998. [10] IETF RFC 2475: An architecture for Differentiated Services, December 1998. [11] IETF RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial

Links, February 1999. [12] IETF RFC 3261: “SIP: Session Initiation Protocol”, June 2002. [13] IETF RFC 3262: “SIP: Reliability of Provisional Responses in the Session

Initiation Protocol (SIP)”, June 2002 [14] IETF RFC 3264: An Offer/Answer Model with the Session Description Protocol

(SDP), June 2002. [15] IETF RFC 3265: Session Initiation Protocol (SIP)-Specific Event Notification,

June 2002. [16] IETF RFC 3311: The Session Initiation Protocol (SIP) UPDATE Method,

September 2002. [17] IETF RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for

Asserted Identity within Trusted Networks, November 2002. [18] IETF RFC 3411: An Architecture for Describing SNMP Management

Frameworks; IETF RFC 3414: Virtual User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), December 2002.

[19] IETF RFC 3489 – STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), March 2003.

[20] IETF RFC 3515: The Session Initiation Protocol (SIP) Refer Method, April 2003. [21] IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications, July

2003. [22] IETF RFC 3551: RTP Profile for Audio and Video Conferences with Minimal

Control, July 2003. [23] IETF RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples,

December 2003. [24] IETF RFC 3711: The Secure Real-Time Transport Protocol (SRTP), March

2004. [25] IETF RFC 3768: Virtual Router Redundancy Protocol (VRRP), April 2004. [26] IETF RFC 3840: Indicating User Agent Capabilities in the Session Initiation

Protocol (SIP), August 2004. [27] IETF RFC 3891: Session Inititation Protocol (SIP) “Replaces” Header,

September 2004. [28] IETF RFC 3911: Session Inititation Protocol (SIP) “Join Header”, October 2004.

© EUROCAE, 2012

75

[29] IETF RFC3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3), September 2004.

[30] IETF RFC 4235: An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP), November 2005.

[31] IETF RFC 4346: The Transport Layer Security (TLS) Protocol - Version 1.1, April 2006.

[32] IETF RFC 4566: SDP: Session Description Protocol, July 2006. [33] EUROCONTROL. “Voice Communication System (VCS) Procurement

Guidelines”, Ed. 2.0, February 2005. [34] ITU-T. Rec. G.711. “Pulse Code Modulation (PCM) of Voice Frequencies”,

November 1988. [35] ITU-T. Rec. G.728. “Coding of Speech at 16 Kbit/s Using Low-delay Code

Excited Linear Prediction”, September 1992. [36] ITU-T. Rec. G.729 “Coding of Speech Signals at 8 kbit/s using Conjugate-

Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), January 2007.

[37] EUROCAE ED-137 “Interoperability Standards for VoIP ATM Components, Part 2: Telephone”

[38] EUROCAE ED-138 “Network Requirements and Performances for Voice over Internet Protocol (VoIP) for Air Traffic Management (ATM) Systems” Part 1: Network Specification

[39] EUROCAE WG67-2_V01_RTP_HEADER_EXTENTION – Frequentis AG [40] EUROCAE WG67_BSS_03_B – SELEX Communications [41] ETSI EN 300 676-1 V1.4.1 (2006-09) “Electromagnetic compatibility and Radio

spectrum Matters (ERM); Ground-based VHF hand-held, mobile and fixed radio transmitters, receivers and transceivers for the VHF aeronautical mobile service using amplitude modulation; Part 1: Technical characteristics and methods of measurement”

© EUROCAE, 2012

76

ANNEX B

BEST SIGNAL SELECTION AND AUDIO LEVEL QUALITY INDEX RECEPTION

B.1 OBJECTIVES OF THIS ANNEX

The objective of this Annex is to provide a definition of Signal Quality Information for Best Signal Selection (BSS) and a brief description of the most commonly used methods employed to perform it. This Annex considers BSS operation within an ATM environment and the use of IP networks for connecting the different infrastructures.

B.2 BSS DEFINITION

Within a radio system where there is more than one incoming signal source, it is necessary to select the best signal source available. The Best Signal Selection is an automatic method for selecting the best signal source at any instant. The BSS (also nominated Receiver Voting) is performed through the continuous monitoring of a parameter that is correlated to the quality of the received signal. Comparing the magnitude of this parameter measured in each of the Rx paths allows the choice of Best Signal Selection to be made. The entity performing the Receiver voting can use a combination of multiple parameters in order to ensure that the signal with the best quality is selected.

B.2.1 Parameters

This section identifies which parameters can be employed in measuring the signal quality and at the same time easily permits calculations to be performed for real time monitoring. In the receive path, between the antenna and operator console, it is possible to identify two main points where the signal quality estimation can be performed; the first is located at the Ground Station Computer, Controller (GSC) or Radio itself and the second is located within the Voice Communication System (VCS). The main parameters that can be used for monitoring the quality of the signal are defined below: RSSI: The Received Signal Strength Indication is a measure of the carrier’s energy, it is normally expressed in dBm and a dedicated circuit measures it. This circuit outputs an electrical signal or a numerical value proportional to the Received Signal Strength. The RSSI can be used also for providing indications about the presence of activity on a Radio Channel. This functionality is used by the CSMA/CA (802.11) algorithm in order to check if a channel is free for starting a transmission. The RSSI is normally evaluated at the IF stage within the RX equipment. When there is no IF stage the measurement is made directly at base-band level, where the DC level is proportional to the carrier amplitude. With modern Receivers, that include microprocessors, Digital Signal Processors (DSP) and Ethernet connectivity, the processing power is powerful enough to calculate the RSSI in real Time. Giving the RSSI directly, in dBm, no scale calibration is requested and consequently the provided value is absolute and manufacturer-independent. C/N Ratio: The C/N ratio is measured in a manner similar to the way the signal-to-noise ratio (S/N) is measured, and both specifications give an indication of the quality of a communications channel. However, the S/N ratio specification is more meaningful in practical situations. The C/N ratio is commonly used in satellite communications systems to point or align the receiving dish; the best dish alignment is indicated by the maximum C/N ratio. The C/N is specified in dB, it is the ratio between the power of the carrier of received signal and the total received noise power. If the incoming carrier strength is Pc and the noise level is Pn, then the carrier-to-noise ratio, C/N, in dB is given by the formula:

C/N = 10 Log10 (Pc/Pn)

© EUROCAE, 2012

77

If the RSSI value is available, estimating the noise power in the IF band, allows the calculation of the C/N ratio in a direct way. Similar to the RSSI measurement, the provided value is very accurate, normally within a +/-1dB tolerance. S/N Ratio: The SNR is defined as the ratio between the amplitude of a signal and the amplitude of noise in the audio band. It is defined for a specific frequency (e.g., 1 kHz test tone) and for a well-specified noise band. The SINAD (Signal to Noise Ratio and Distortion) could be generally used instead of SNR. This is a relationship in which noise is also considered the distortion of the in band signal. It is easier to perform an S/N calculation in a laboratory, where a reference signal is normally available. In a Radio receiver or in a VCS is becomes more complicated to perform this calculation in real time. AGC voltage: In the old AM receivers, with diode demodulation, the mean value of demodulator output voltage was normally used to drive the Automatic Gain Control (AGC) circuit. This voltage is proportional to the carrier amplitude. The relationship between AGC voltage and the carrier amplitude usually isn't linear, and it depends on the circuit employed. Moreover, the AGC voltage relationship isn't absolute and it depends on the manufacturer’s implementation and on the receiver model. This behaviour can be a problem and it requires the definition of a reference table. Therefore, this parameter is considered the least reliable to be employed in order to implement BSS schemes. The Figure 22 below shows the relationship between AGC Voltage and Receiver Gain.

FIGURE 22: AGC VOLTAGE LAW

The use of AGC Voltage as information of the received signal quality can be supported only for reasons of backwards-compatibility with the older type of receivers, assuming that this equipment will be integrated within the IP network through an actual Radio Gateway. Squelch threshold: The squelch circuit stops the audio activity if the received signal is below an established threshold. The threshold is normally programmable on the strength of the received signal (i.e. RSSI) or on the SNR at RF (i.e. C/N Ratio). Civil ATC controllers do not handle the Squelch threshold in their normal operations. The reason is that the remote sites are complex installations, with a lot of radio equipment and the presence of complex filtering systems. The Squelch threshold is a parameter that is directly related to the remote site design and setup (e.g. coverage, positioning issues, etc…). The management of such a parameter directly by an ATC controller instead of by maintenance staff could cause denial of service problems.

© EUROCAE, 2012

78

Even if some military ATC controllers could use this parameter, it is necessary to take into account that modern ground-air communication systems are controlled by a proprietary RCMS system, on which it is possible to manage such a parameter. Basically, the squelch threshold isn’t a measure of the received signal strength. Moreover, this parameter doesn’t change its value dynamically. Therefore, the SQL Threshold as BSS information method should not be adopted, for compatibility with older systems. PSD: The Power Spectral Density estimation is another method for detecting the quality of the received signal. Using the Fast Fourier Transform algorithm, the PSD can be computed easily; this is made possible due to the high processing power available in modern RTX and VCS systems. Partitioning the audio band into many sub-bands, and setting a weighting for each sub-band in function of its importance to other bands, improves the quality information provided by the PSD measurement. An example of weighting in audio band filtering is the psophometric filter (defined by ITU-T), where the frequency response is proportional to the sensibility of the human ear.

B.3 ARCHITECTURES

In modern ATC infrastructures the four main elements that can be identified in the receive path between antenna and Control Centre include the Radio Receiver, the Radio Ground Station Controller, the Voice Communication System and the Network. The network is usually divided in two parts, the Radio equipment internal LAN and the external WAN. The Figure 23 shows a simplified diagram of a connection from a Radio equipment to a VCS, where a Single Transceiver operates under the control of a VCS.

FIGURE 23: SIMPLE RADIO-VCS CONNECTION

In real applications many Transceivers are operating concurrently at the same site and they are connected directly to the VCS. More complex configurations can be defined if separate geographical sites are used and the connection to the VCS is indirect through the Network. Some elementary configurations are listed below: 1. RTX, RX and TX are positioned at the same location as the VCS. 2. Radio equipment is split between several geographical sites; 3. Climax configuration. The modern radio equipment is built of microprocessors, DSP and Network Interfaces. Its high signal processing power provides the capability to calculate C/N, SNR and RSSI in real time. The BSS calculation will be a standard feature of a modern digital radio system. In a digital connection, using a packet network, the degradation of voice quality is usually due to the loss of packets. For all configurations described, the connection from a Radio equipment to a Control Centre is done over the IP network; legacy dial-up networks could however still be used for backup or for last resort purposes. The quality of an IP connection is expressed by the packet loss percentage. This value is usually known through the QoS infrastructure or through the service monitoring within the network. The maximum number of radio in a Climax configuration using radios with 25 KHz spacing is equal to 5.

© EUROCAE, 2012

79

The Quality Index value (calculated by the Radio Receiver and placed within RTP header) and knowledge of the packet loss rate provide sufficient information to allow the best signal source to be selected. Consequently, the Receiver voting functionality can be performed, at a point within the receive path, where information converges from many sources. This point may be located at the GSC, VCS or at a dedicated device within the network When using climax (off-set carrier transmission) operation, the radio system has many receivers (up to five) as signal sources. Voting operations are usually concentrated at the VCS site (embedded within the VCS or performed by an independent network entity). The voter dynamically calculates the received quality from every source and selects the received path with the best signal.

FIGURE 24: CLIMAX CONFIGURATION; VOTER NOT INCLUDED WITHIN VCS

© EUROCAE, 2012

80

FIGURE 25: CLIMAX CONFIGURATION; VOTER EMBEDDED WITHIN VCS

B.4 QUALITY INDEX CODING

As described in section 5.1 the Quality Index is inserted in the RTP header by the Receiver and is transported through the network, with the voice packet. The Quality Index placed within the Header Extension has to be flexible for future applications, this means reserving enough bits for coding each chosen parameter (AGC, RSSI…). The parameter type can be predefined or negotiated during the opening of SIP session, with SDP message body exchanges; in this case each system declares the types of parameter it is able to manage, in a similar way to Codec negotiation. This doesn't preclude any dynamic change during the reception, or in other words the parameter type can be changed without restarting the session.

B.4.1 Parameters coding

The Signal Quality Information for BSS can be coded within the RTP header extension, by using a simplified coding methodology defined by two fields. The first field contains the BSS Value (5 bits) and the second field defines the type of BSS parameter used (3 bits).

SQI Value (5 bits) SQI Method(3 bits)

As it is reported in section 5.6.2, the Rx message has two fields dedicated at SQI, comprising of 8 bits in total. • BSS-qidx (5 bit): BSS Quality Index • BSS-qidx-ml (3 bits): Methods List Representing the measured BSS quality index value by using only 5 bits requires the use of a logarithmic scale (dB, dBm); on the other hand, the logarithmic scale also compresses the dynamic range of values and reduces the required resolution. For example, the RSSI method has a realistic range defined from -114dBm to +10dBm. This range extends from the noise floor level (-114dBm) to a signal received from a near-by radio (+10dBm).

© EUROCAE, 2012

81

Therefore, the use of only 5 bits (32 levels) provides enough resolution to represent the RSSI value and every other proposed BSS method. The table below summarizes the BSS parameters; this defines the binary Code for each BSS method (i.e. BSS-qidx-ml), typical range, the necessity of a real time calculation and the proposed measurement Unit. The 4th column defines whether the calculation can be performed in real time. The real time processing is only possible if the time required to process the signal is less than the voice packetizing time. It is assumed that the reference voice packetizing time is 20ms.

Code BSS Method Typical Range Real Time Unit

0x0 RSSI -100, -70 Yes dBm (16 steps)

0x1 AGC Voltage +1, +4 Yes V

0x2 C/N +10, +70 (2 dB steps)

No dB

0x3 PSD ... No dB/Hz dBm/Hz

0x4

0x5 Vendor specific Methods

0x6

0x7

TABLE 22 – BSS PARAMETERS

The adoption of the BSS signal quality index methods are defined as follows: • Mandatory: RSSI • Optional: AGC Level, C/N, PSD • Proprietary: Vendor specific methods

B.4.1.1 Classes

The bss-value should be used for providing BSS information that is sub-divided into classes; in this case the provided information can be qualitative or quantitative. An example of level partitioning into classes is provided by Table 23 below, where a 6dBm step has been used. 0 1 2 3 4 5 6

<= -114 -113 to -108 -107 to -102 -101 to -96 -95 to -90 -89 to -84 >= -83

TABLE 23 – LEVEL PARTITIONING

The old S-Meters system for VHF/UHF (refer to Table 24), frequently used in Ham Radio equipment, is an example of a scoring method with 14 classes or levels. The Grouping of many of these classes, in order to obtain a total of 8 classes, could be an example of how a BSS Quality Index (BSS-qidx) is applied.

© EUROCAE, 2012

82

S-Meters dBm µV/50 ohm

0 -147 0,01

1 -141 0,02

2 -135 0,04

3 -129 0,08

4 -123 0,16

5 -117 0,32

6 -111 0,63

7 -105 1,26

8 -99 2,54

9 -93 5

9+10dB -83 16

9+20dB -73 50

9+30dB -63 160

9+40dB -53 500

TABLE 24 – S-METERS FOR VHF/UHF

B.5 CONCLUSION

After this technical analysis, it is possible to summarize what has been presented in the previous paragraphs. The measurement methods for RSSI and C/N are absolute and they don’t require any calibration; the adoption of these methods is within the scope of many modern digital communication systems and their use should be mandatory. On the other hand, PSD and S/N evaluations are not likely to be implemented within ATC radio equipment. Therefore, BSS signal quality index shall primarily be determined by RSSI, or C/N methods, or even a combination of both methods. It is very important that the signal quality for BSS processing is measured within the radio equipment at a point where the dynamic range of the signal is at a maximum (because later the signal is reduced by the dynamics of the CODEC). Moreover, in contrast to analogue systems, the digital connection between the Radio equipment and Control Centre does not affect the quality of the signal. Packet loss estimation can also be evaluated, in order to optimize the best signal selection. The other methods such as Automatic Gain Control (AGC) can still be used for backwards compatibility with the older generation systems and with older types of installation.

© EUROCAE, 2012

83

ANNEX C

CLIMAX CONSIDERATIONS

C.1 PURPOSES

Due to environmental or infrastructure constraints, some control sector coverage can not be achieved by only one ground station. In response to such operational constraints it is necessary to use simultaneously several independent ground stations operating with the same frequency. Technically feasible up to five stations (normalized by ICAO annex 10, but usually limited to 4 in practice), this process is called offset-carrier. The offset-carrier implementation is mainly driven by the need to: - reduce the influence of terrain mask especially for low-level sectors - enable extended range coverage - cope with the unavailability or the lack of suitable location of existing ground

stations - provide redundancy for back-up In Europe, most of the offset-carrier frequencies are operated in two legs (68%) or three legs (28%) configuration.

C.2 PRINCIPLE

In the ground-to-air direction (controller to pilot), the same audio signal is transmitted by all the ground stations involved. To prevent heterodyne interference in the overlapping coverage area of the transmitters, the associated carriers must be offset while staying within the channel width (25 kHz). This way, the signal resulting from the recombination of the carriers within the airborne receiver is shifted out of the audio bandwidth. For instance, for two-carrier systems the offsets are set to +/- 5 kHz. In the air to ground direction (pilot to controller) the audio signal received from all or part of these ground stations (depending on the relative location of the aircraft) is sent back to VCS.

C.3 ISSUES RAISED

The offset-carrier technique induces some specific interference that impacts the service quality. Thus, its use must be restricted to the justified cases only.

C.4 ECHO EFFECTS

Offset-carrier echo, also called “Barrel effect”, occurs when two or more identical audio signals are received and demodulated with relative time delays. This phenomenon can appear either on board or on ground where these incoming signals are combined in the audio circuitry of the airborne receiver or of the VCS respectively. For ground-to-air communications, the echo effects are mainly limited to the overlapping coverage area of the ground transmitters where signal strengths are rather equal (power ratio less than 8dB in practice – no predominance). This area can be more or less complicated due to topography (diffraction) and fluctuate in accordance with propagation change (atmospheric conditions). For air-to-ground communication, this area can be widespread due to AGC action of the ground receivers capable to compensate a large variation of signal levels. In most cases, the relative time delays result from the combination of ground-ground transmission media that are used for linking the ACC to the corresponding remote stations. These time delays can vary to a large extent - according to the type of medium : leased phone lines, radio links, optic fibre

links, VSAT links, private copper cable - or according to new technology as VoIP using Voice packetization process.

© EUROCAE, 2012

84

C.5 SIGNAL FADING

In addition to echo effects, some particular signal fading may happen in the overlapping coverage area. It can be noticed either on board or on ground reception. This phenomenon is mainly due to phase differences between the incoming audio signals that are received via different paths. Moreover, this situation can worsen when carrier-to-noise threshold in implemented in the airborne receiver. Indeed, receiver sensitivity may be deteriorated in the overlapping coverage area with such a particular squelch circuitry, Contrary to echo effects that result from relative delay of several milliseconds, signal fading in mainly due to both delay differences less than a millisecond (fluctuant part that varies according to aircraft movement) and the “route” used by the audio signal along the ground/ground transmission path. For ground-to-air communications, when two (or more) carriers are received with similar level by the aircraft, both RF signals are demodulated and the corresponding audio signals are combined on the output line. Hence, the output audio signal to be delivered to pilot headset will be affected both by the relative time delays of the incoming RF signals (echo effects) and the relative phase of the corresponding modulation (signal fading). It will be more or less attenuated, distorted and can be cancelled at specific frequencies. In the worst case (opposite phase – no relative time delay), this output voice signal can be attenuated up to cancellation. For air-to-ground communications, any message received by all or part of the ground stations taking part in climax is sent to VCSS with the same level after AGC compensation. If no selection device is implemented, these incoming signals are simply mixed which entails the same problem as aboard.

C.6 IMPLEMENTATION PRECAUTIONS

In the few justified cases where offset-carrier is strictly needed, particular precautions have to be adopted to reduce the impact of the various disturbance effects. IP technology and RTP protocol provide additional information as Time Stamping which can be used to synchronize VCS and radio equipment. Additionally, NTP protocol or local time synchronization can be used by the equipments to provide accurate time stamp which is needed to calculate the time delay between all radios and the VCS involved in a Climax mode.

C.7 AIR-TO-GROUND COMMUNICATIONS

In the case of air-to-ground communications, all the offset-carrier drawbacks can be easily avoided by introducing Best Signal Selection device. With such a voting process, only one of the incoming audio signals is delivered to controller headset with no echo and no risk of signal fading.

C.8 GROUND-TO-AIR COMMUNICATIONS

a) Echo effects If this phenomenon can be countered by introducing Best Signal Selection device on controller reception, time delay differences in ground-ground transmission need to be compensated for controller to pilot communications. This could be adjusted by introducing delay line at VCS or/and Radio equipment.

© EUROCAE, 2012

85

ANNEX D

SECURITY CONSIDERATIONS

The first assumption taken in this document was that the underlying IP network that transports the SIP protocol and RTP extender voice packet traffic is a closed network and therefore secure. Although at IP level this infrastructure is by no means public, potential risks will however be considered and for some of them an optional protection mechanism is proposed. A malicious third party who gains access to the IP infrastructure supporting SIP and RTP extender voice traffic may be able to initiate SIP Call to radios or to intercept legitimate packets and attempt to send their own spoofed packets towards one or both Endpoints.

D.1 SIP CALL CONTROL

SIP signalling traffic must be viewed with considerable suspicion, malformed SIP messages should be discarded. If possible originator address shall be identified and any unknown originator address shall be rejected. As the SIP signalling passes through various servers on route to its destination, the SIP messages acquires information about where the message came from and what devices it passed through. Since global networks are made up of a mesh of service provider networks this information gets passed from network to network. It is therefore important to strip all this information from the signalling prior to it being passed from one network to another. This prevents internal network addresses and client address details from being propagated

D.2 VOICE PACKET SPOOFING

Depending of the processing power of the system hardware that performs the processing of media streams, the extension of the authentication mechanism to voice packets may or may not be effective. If sufficient processing power is available, the authentication code may be added as an extension to every voice packet header as well as the real time signalling extension. If no authentication mechanism is employed and the attacker is unable to suppress the legitimate media flow towards the attacked target, the target will be able to detect that an attack is in progress. The detection is performed by observing a non uniform increment in “sequence number” and “timestamp” fields within the header of the incoming voice packets.

D.3 DENIAL OF SERVICE (DOS) ATTACKS

A “Denial of Service” attack consists in a malicious party targeting a very high flow of packets created in such way so as to pass over the regular filters positioned within the network. Depending on the processing power of the system hardware that performs the processing of the media streams, a DoS type of attack may or may not lead to the target entering in a default state. An authentication mechanism is not effective at preventing a DoS attack; moreover it will enhance the destructiveness of such an attack.

© EUROCAE, 2012

86

ANNEX E

RTP HEADER EXTENSION BIT RATE CALCULATION

In the following table a 20 ms packetization period for audio and audio + signalling packets is assumed. For packets carrying signalling only, a repetition time of 200ms (default value) is assumed. Table 25 describes the bit rate calculation on the IP Layer with respect to the three different RTP packet types. • The voice packet describes the RTP packet type where only audio and no

signalling information is transported; • The Header Extension (HE) signalling packet is the RTP packet type where only

signalling is transported, without any audio payload. This type can be used to inform receivers about the state of its corresponding transmitter in a TX/RX configuration;

• Header Extension (HE) audio + signalling packet consists of audio and signalling information.

voice packet HE signalling packet HE audio + signalling packet

Bytes Bytes Bytes

Audio payload 160 Audio payload 0 Audio payload 160

RTP header extension 0 RTP header extension 8 RTP header extension 8

RTP header 12 RTP header 12 RTP header 12

UDP header 8 UDP header 8 UDP header 8

IP header 20 IP header 20 IP header 20

Total 200 Total 48 Total 208

Packet duplication 1 Packet duplication 1 Packet duplication 1

TX period (ms.) 20 TX period (ms.) 200 TX period (ms.) 20

Bit / time interval 1600 Bit / time interval 384 Bit / time interval 1664

Bit / sec 80000 Bit / sec 1920 Bit / sec 83200

Frequency 50 Frequency 5 Frequency 50

Bytes/sec 10000 bytes/sec 240 bytes/sec 10400

TABLE 25 – BIT RATE CALCULATION FOR 3 DIFFERENT RTP PACKET TYPES

© EUROCAE, 2012

87

ANNEX F

DYNAMIC DELAY COMPENSATION

F.1 FUNCTIONAL DESCRIPTION OF THE METHOD

The solution concept for dynamic time compensation described hereafter is based on estimating the dynamic one-way network delay between the VCS and the GRS. If absolute time is available the one-way delay can be measured directly. If only relative time values are available, then an estimation based on round trip delay measurement is used. In order to get an accurate one way network delay, the VCS endpoint transmits in regular intervals a Request for Measurement Message (RMM) to all GRS transmitter endpoints of a CLIMAX coverage group. The GRS transmitter endpoints answer with a Measurement Answer Message (MAM) to the VCS endpoint, where all relevant information is included. After received the MAM from all GRS endpoints, the VCS endpoint can estimate all end-to-end one-way delays (microphone to antennas) and is able to compensate the audio delay within a CLIMAX group. The audio delay compensation can be done either by initiate additional audio delay or by sending CLD information to the corresponding GRS endpoints.

F.1.1 Preconditions for a Reliable Operation

There are no preconditions required.

F.1.2 Format of Time Values

All time formats, from time intervals and from time stamps, using time values based on ticks. Ticks coming from TDM based systems and are using an 8 kHz sampling clock. A time system based on this sampling clock enables a resolution of 125 µs. This time format is used because all codec defined in ED-137A Part 1 are using RTP timestamp values based on ticks of 125 µs.

F.1.3 Quality of Time Values

For a simplified identification of the quality of the time values from the VCS to the GRS and form the GRS to the VCS, the following Time Quality information shall be used: • Time Quality:

- 0: free run No synchronisation with any external time source

- 1: Synchronised An external time source is available and the GRS is synchronised

© EUROCAE, 2012

88

F.2 ONE WAY AUDIO DELAY ESTIMATION

VCS VoIP Network

Interface(s)

Mic.

CWP

Delay Line

Jitter Buffer

Tp1 Tn1 Td1Tj1GRS 1

Packing

Jitter Buffer

TdTx

Tj2 Tn2

Packing

Response

Tp2

System Delay Ts1

digitalSystem

analogSystem

VCS System Delay Tv1

T1T2

T3T4

FIGURE 26: VOICE DELAY: CWP – ANTENNA

Figure 26

The VCS is responsible for the estimation of the one way audio delay from the CWP to the antenna TdTxIP. The overall delay TdTxIP can be calculated by the following formula (see ):

TdTxIP = Tv1 + Tp1 + Tn1 + Tj1 + Td1 + Ts1

The VCS internal system delayTv1 and the packetizing delay Tp1 are constant and known by the VCS. The GRS system internal delay Ts1 is also constant but unknown for the VCS. The network delay Tn1 and the delay within the jitter buffer Tj1 are variable during a SIP session. Tn1 is unknown by the VCS and must be estimated by operating network delay measurements between the VCS and the GRS endpoint. The current jitter buffer delay Tj1 can be determined by the GRS. In order to estimate the current one way audio delay from the VCS to the GRS endpoint, the VCS transmits a Request for Measurement Message (RMM) to the GRS (Figure 27

Figure 27

). This Request for Measurement message is an RTP or an R2S packet containing a timestamp T1 and time quality information (free running or synchronised). The timestamp T1 represents the packet transmit time at the VCS endpoint. The time quality information (Time Quality VCS - TQV) defines the quality of the timestamp T1. If the time quality VCS (TQV) is one, the timestamp T1will represent an absolute time value (i.e. the VCS is synchronised to an external time server). If TQV is zero, the timestamp T1 will represent a relative time value (i.e. the VCS is not synchronised to an external time server). When the GRS endpoint receives an RMM message, it has to measure the time T2 ( ). T2 representing the local time at which the GRS endpoint receiving the RMM message.

© EUROCAE, 2012

89

As response to the RMM message the GRS endpoint send a Measurement Answer Message (MAM) to the VCS endpoint (Figure 27). The measurement answer message is also an RTP or R2S packet containing the following information (see Figure 26 and Figure 27): • T1: Represents the packet transmit time at the VCS endpoint. • T2: Represents the packet reception time at the GRS endpoint. • Tsd: Represents the time duration between receiving the RMM message and

transmitting the MAM message. If T3 is defined as the packet transmit time of the MAM message at the GRS endpoint towards the VCS endpoint, then Tsd = T3 – T2.

• Tj1: Is defined as the current delay of the RMM message (RTP or R2S) packet) in the GRS jitter buffer.

• Note: Therefore it is necessary that the RMM message is an RTP or R2S packet, because these packets represent a number of audio samples.

• Tid – Internal Delay: Represents the internal delay of audio from the jitter buffer output to the antenna. This value is defined as:

Tid = Td1 + Ts1

Tid is the delay time which is sent from the GRS endpoint to the VCS endpoint • TQG - Time Quality GRS: The time quality information (TQG) defines the quality

of the timestamp T2. If the time quality (TQG) is one, the timestamp T2 will represent an absolute time value (i.e. the GRS is synchronised to an external time server). If TQG is zero, the timestamp T2 will represent a relative time value (i.e. the GRS is not synchronised with the required accuracy to an external time server).

• NMR- New Measurement request: This NMR field is used to inform the VCS about an event that requires a new estimation of the one way audio delay. If the NMR value is one, the GRS request new audio delay estimation. If NMR is zero, the GRS doesn’t request a new estimation of the one audio delay.

The current one way audio delay estimation depends on the values of TQV and TQG. When the VCS endpoint receives a MAM message, it has to measure the time T4. T4 representing the local time at which the VCS endpoint receiving the MAM message.

© EUROCAE, 2012

90

FIGURE 27: MESSAGE FLOW EXAMPLE FOR ONE-WAY DELAY ESTIMATION

F.2.1 Absolute time available

If the values from TQV and TQG are one, i.e. the VCS and the GRS are synchronized and using absolute time values with the required accuracy, then the one way network delay Tn1 can be estimated by simply subtracting T1 from T2.

Tn1 = T2–T1 The current one way audio delay TdTxIP from the CWP to the antenna can be calculated by using the information from the measurement answer message (MAM) and the known values of the internal VCS delayTv1 and the packetizing delay Tp1:

TdTxIP = Tv1+Tp1+T2–T1+Tj1+Tid

F.2.2 Relative time available

If only one of the two systems (GRS or VCS) are not using absolute time values, then the one way network delay must be estimated by dividing the round trip delay (round trip time – RTT) by two. In that case only the current round trip delay can be computed exactly. The network delay in one direction can be approximately computed assuming symmetrical network delay. Therefore assuming Tn1 = Tn2, the one way network delay Tn1 can be estimated by:

Tn1 = (T4–T1–Tsd)/2 The current one way audio delay TdTxIP from the CWP to the antenna can be calculated by:

TdTxIP = Tv1+Tp1+Tn1+Tj1+Tid

© EUROCAE, 2012

91

ANNEX G

ACRONYMS

Ack Acknowledge AGVN Air Traffic Services Ground Voice communications Network A/G Air/Ground AGC Automatic Gain Control ALGs Application Level Gateways AM Amplitude Modulation ANSP Air Navigation Service Provider API Application Program Interface ATC Air Traffic Control ATM Air Traffic Management ATS Air Traffic Services ATSU Air Traffic Service Unit AVP Audio/Video Profile BSS Best Signal Selection CoS Class of Service CNAME Canonical Name (item in SDES RTCP message) as defined in RFC3551

[22] C/N Carrier to Noise CSMA/CA Carrier Sense Multiple Access with Collision Avoidance CSRC Contributing SouRCe CWP Controller Working Position dB Decibel DiffServ Differentiated Services DNS Domain Name Service DoS Denial of Service DSCP DiffServ Code Point DSP Digital Signalling Processor ECMA European Computer Manufacturers Association FFT Fast Fourier Transform G/G Ground/Ground GRS Ground-based Radio Station HE Header Extension HMAC Hashed Message Authentication Code HMI Human Machine Interface HTTP HyperText Transfer Protocol

© EUROCAE, 2012

92

IEEE Institute of Electrical and Electronic Engineers IETF Internet Engineering Task Force IF Intermediate Frequency IP Internet Protocol ITU-T International Telecommunication Union – Telecommunication

standardization sector LAN Local Area Network LD-CELP Low Delay - Code Excited Linear Prediction MOS Mean Opinion Score MRxF1 Main Analog F1 Radio Receiver MRxF2 Main Analog F2 Radio Receiver MTxF1 Main Analog F1 Radio Transmitter MTxF2 Main Analog F2 Radio Transmitter MSC Message Sequence Chart NAPT Network Address Port Translation NAT Network Address Translation PABX Private Automatic Branch eXchange PCM Pulse Code Modulation PDU Protocol Data Unit PLC Packet Loss Concealment PSD Power Spectral Density PSTN Public Switched Telephone Network PT Payload type (In context of RFC3550 [21]) PTT Push-To-Talk PWE3 Pseudo Wire Emulation Edge-to-Edge QoS Quality of Service Rec. Recommendation RF Radio Frequency RFC Request For Comments RR Receiver Report (a RTCP message) RRC Radio Remote Control RRCE Radio Remote Control Equipment RSSI Received Signal Strength Indication RTCP Real-time Control Protocol RTP Real-time Transport Protocol RTT Round-Trip-Time RTx Radio Transceiver Rx Radio Receiver R2S Real Time Supervision Session

© EUROCAE, 2012

93

S/MIME Secure / Multipurpose Internet Mail Extensions SDES Source Description (a RTP session context information) SDP Session Description Protocol SIP Session Initiation Protocol SNR Signal to Noise Ratio SQL SQueLch SQI Signal Quality Information SQP Signal Quality Parameter SR Sender Report (a RTCP message) SRxF1 Standby Analog F1 Radio Receiver SRxF2 Standby Analog F2 Radio Receiver SSRC Synchronisation SouRCe STxF1 Standby Analog F1 Radio Transmitter STxF2 Standby Analog F2 Radio Transmitter STUN Simple Traversal of UDP through NAT TCP Transmission Control Protocol TDM Time Division Multiplexing TLS Transport Layer Secure protocol TU Transaction User TWR Tower Tx Radio Transmitter UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Universal Resource Identifier UHF Ultra-High Frequency VAD Voice Activity Detection VCS Voice Communications System VHF Very High Frequency VoIP Voice over the Internet Protocol WAN Wide Area Network

© EUROCAE, 2012

94

ANNEX H

LIST OF EUROCAE WG-67 SG1 CONTRIBUTORS (IN ALPHABETICAL ORDER)

SURNAME NAME COMPANY

ALIMENTI Alessandro SELEX

BALEN Rafael NUCLEO

BICA Dumitru TOPEX

BRUTE DE REMUR Valérie THALES-AS

DUMAS Laurent THALES-AS

DUMERCQ Jean TELERAD

DUMITRESCU Cosmin ROMATSA

FANTAPPIE Pierluigi SELEX

GARCIA Arturo NUCLEO

HAINDL Bernhard FREQUENTIS

HASSELKNIPPE Martin PARK AIR SYSTEMS

HECKMANN Patrick INEO-ES

KAMPICHLER Wolfgang FREQUENTIS

LAKE Andrew PARK AIR SYSTEMS

LAUPRETE Christophe DSNA

LEROY Christophe CSSI

MAIER Bernhard ROHDE & SCHWARZ

MALTESE Paolo SELEX

MARIOTTE Patrice TELERAD

MARTIN Eric DGAC DTI

MARTIN Miguel AENA

MATAR Mickael FREQUENTIS

MERULLI Davide SELEX

PABLOS GARCIA Sergio INDRA

PALMER John JSP-TELECONSULTANCY

POPESCU Liviu EUROCONTROL

POTIRON Guy DSNA, EUROCAE WG67 CHAIRMAN

POTTIER Herve CS COMMUNICATION & SYSTEMES

SOULIE Xavier TELERAD

STANDEREN Egil THALES-NO

© EUROCAE, 2012

© EUROCAE, 2012

95

VITI Lorenzo SELEX

WASSTOL Bjorn PARK AIR SYSTEMS

WEGER Roberto SITTI

ZOMIGNANI Marcelo INDRA SISTEMAS

ZURR Gernold DFS

92240 MALAKOFF, France Fax: 33 1 46 55 62 65Web Site: www.eurocae.net Email: [email protected]

102 rue Etienne Dolet Tel: 33 1 40 92 79 30


VOLUME 2: TELEPHONE




The European Organisation for Civil Aviation Equipment L’Organisation Européenne pour l’Equipement de l’Aviation Civile


VOLUME 2: TELEPHONE




© EUROCAE, 2012

i

FOREWORD

1. This document “Interoperability Standards for VoIP ATM Components – Volume 2: Telephone” was prepared by EUROCAE Working Group 67 and was accepted by the Council of EUROCAE on 19 January 2012.

2. EUROCAE is an international non-profit making organisation. Membership is open to manufacturers and users in Europe of equipment for aeronautics, trade associations, national civil aviation administrations and non-European organisations. Its work programme is principally directed to the preparation of performance specifications and guidance documents for civil aviation equipment, for adoption and use at European and world-wide levels.

3. The findings of EUROCAE are resolved after discussion among its members and, where appropriate, in collaboration with RTCA Inc, Washington D.C. USA and/or the Society of Automotive Engineers (SAE), Warrendale, PA, USA through their appropriate committee.

4. This document is part of a series of EUROCAE Documents, composed of 5 volumes: • ED-137/1 “Interoperability Standard for VOIP ATM Components –

Volume 1: Radio” • ED-137/2 “Interoperability Standard for VOIP ATM Components –

Volume 2: Telephone” • ED-137/3 “Interoperability Standard for VOIP ATM Components –

Volume 3: European Legacy Telephone Interworking” • ED-137/4 “Interoperability Standard for VOIP ATM Components –

Volume 4: Recording” • ED-137/5 “Interoperability Standard for VOIP ATM Components –

Volume 5: Supervision”. Together the 5 volumes, edition B, replace ED-137A, published in September 2010.

5. This version of the document represents “the minimum specification required for Manufacturers and Users to assure Interoperability between VoIP ATM Telephone Components”. EUROCAE WG67 has updated the previous version of ED137A and created a separated document ED 137 Volume 2 replacing the Part 2 of ED137A, referenced in ICAO document 9896: Á following a series of plug tests, performed by many suppliers in Arlington

in May 2011 and in Sophia Antipolis in June 2011, improving ED-137 concerning the understanding of interoperability requirements between the ATM VoIP components,

Á following discussions with FAA for taking into account US requirements agreeable within the European context.

6. This version is taking into account the EUROCONTROL VoIP in ATM Test Case Specification

7. EUROCAE performance specifications are recommendations only. EUROCAE is not an official body of the European governments; its recommendations are valid statements of official policy only when adopted by a particular government or conference of governments.

8. Copies of this document may be obtained from: EUROCAE

102 rue Etienne Dolet 92240 MALAKOFF

France Tel: 33 1 40 92 79 30 Fax: 33 1 46 55 62 65

Email: [email protected] Web Site: www.eurocae.net

© EUROCAE, 2012

mailto:[email protected]

http://www.eurocae.net/

ii

TABLE OF CONTENTS FOREWORD .............................................................................................................................................i CHAPTER 1 INTRODUCTION ................................................................................................... 1

1.1 BACKGROUND...................................................................................... 1 1.2 ED-137 Volume 2 PRESENTATION...................................................... 3 1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS AND

OPTIONS ............................................................................................... 3 1.4 VERSION TRACKING............................................................................ 4

CHAPTER 2 COMMUNICATION MODEL.................................................................................. 5 2.1 DEFINITIONS......................................................................................... 5 2.2 PROTOCOL STACK .............................................................................. 5

2.2.1 Signalling in an IP AGVN ........................................................ 6 2.2.2 Audio Specifications................................................................ 6

CHAPTER 3 PROFILE STANDARD FOR THE USE OF SIP IN AN AGVN............................... 7 3.1 LOGICAL SIP ENTITIES........................................................................ 7

3.1.1 User Agents ............................................................................ 7 3.1.2 Registrar.................................................................................. 7 3.1.3 Proxy Server ........................................................................... 8 3.1.4 Redirect Server ....................................................................... 8

3.2 SUPPORTED REQUESTS .................................................................... 8 3.2.1 INVITE and RE-INVITE........................................................... 9

3.3 SUPPORTED RESPONSES.................................................................. 9 3.4 SUPPORTED HEADER FIELDS ........................................................... 9

3.4.1 User Agent Request Headers ................................................. 9 3.4.2 User Agent Response Headers .............................................. 10 3.4.3 Registrar Server Request Headers......................................... 12 3.4.4 Registrar Server Response Headers...................................... 12 3.4.5 Max-Forwards ......................................................................... 13 3.4.6 Priority ..................................................................................... 13 3.4.7 Subject .................................................................................... 13 3.4.8 Reason.................................................................................... 14 3.4.9 WG67-Version......................................................................... 14

3.5 MESSAGE BODY................................................................................... 15 3.6 ADDRESS FORMAT.............................................................................. 16 3.7 SECURITY REQUIREMENTS ............................................................... 16

CHAPTER 4 GROUND TELEPHONE FACILITIES.................................................................... 17 4.1 Routine Direct/Indirect Access Call ........................................................ 17 4.2 Call Priority ............................................................................................. 17 4.3 Instantaneous Access Call ..................................................................... 17

4.3.1 Application............................................................................... 17 4.3.2 Establishment Conditions ....................................................... 17 4.3.3 Audio ....................................................................................... 18 4.3.4 Timing Constraints .................................................................. 18 4.3.5 IA Call Signalling Procedures ................................................. 18 4.3.6 IA Call Parameter Values (Timers) ......................................... 19 4.3.7 Interaction with Other ATS Supplementary Services.............. 19 4.3.8 IA Call Message Sequence Charts ......................................... 20

© EUROCAE, 2012

iii

4.4 OVERRIDE CALL................................................................................... 24 4.4.1 Establishment Conditions ....................................................... 24 4.4.2 Audio ....................................................................................... 24 4.4.3 Timing Constraints .................................................................. 25 4.4.4 OVR Call Signalling Procedures ............................................. 25 4.4.5 OVR Call Parameter Values (Timers)..................................... 29 4.4.6 OVR Call Loop Closure Detection method ............................. 29 4.4.7 OVR Call Loop Closure Rejection method ............................. 30 4.4.8 OVR Call A/G monitoring method........................................... 30 4.4.9 Interaction with Other ATS Supplementary Services.............. 30 4.4.10 OVR Call Message Sequence Charts..................................... 31

4.5 CALL HOLD............................................................................................ 35 4.6 CALL TRANSFER .................................................................................. 35 4.7 “MEET ME” CONFERENCE .................................................................. 35 4.8 BROADCAST CONFERENCE............................................................... 35

4.8.1 Operational Requirements ...................................................... 35 4.8.2 Interoperability General Requirements ................................... 35 4.8.3 Execution of a Conference...................................................... 36

4.9 INTRUSION............................................................................................ 41 4.9.1 Interoperability General Requirements ................................... 41 4.9.2 Execution of Priority Call Intrusion.......................................... 42 4.9.3 Message Sequence Charts..................................................... 43

4.10 POSITION MONITORING...................................................................... 48 4.11 PRESENCE INFORMATION ................................................................. 49 4.12 DETECTION OF LINK CONNECTION LOSS........................................ 49 4.13 AUDIBLE TONES................................................................................... 49

ANNEX A REFERENCES ...................................................................................................... 52 ANNEX B ACRONYMS .......................................................................................................... 54 ANNEX C LIST OF EUROCAE WG-67 CONTRIBUTORS.................................................... 56

© EUROCAE, 2012

iv

FIGURE INDEX Figure 1 – Vienna Agreement ................................................................................................................. 2 Figure 2 – IA Call from A-party to B-party. IA call established and A-party clears call ......................... 20 Figure 3 – IA Call from A-party to B-party. IA call established, B-party responds ................................ 21 Figure 4 – IA Call from A-party to B-party. IA call established, B-party responds, then A-party de-

activates IA key ...................................................................................................................... 21 Figure 5 – Monitoring not configured on A-party’s VCS. IA Call from A-party to B-party. IA call

established, B-party responds, then B-party de-activates IA key .......................................... 22 Figure 6 – Monitoring not configured on both VCSs. IA Call from A-party to B-party. IA call

established, A Ą B: talking & BĄ A: talking, A-party de-activates IA key and then re-activates IA Key ..................................................................................................................... 22

Figure 7 – IA Call from A-party to B-party. IA call established, A Ą B: talking & BĄ A: talking, A-party de-activates IA key and B-party de-activates IA key ............................................................. 23

Figure 8 – IA Call from A-party to B-party. IA call is rejected................................................................ 23 Figure 9 - OVR call from A-party to B-Party, OVR call established and A-Party clears call ................. 31 Figure 10 - OVR call from A-party to B-Party, OVR call established and B-Party clears call ............... 32 Figure 11 - OVR call from A-party to B-Party, B-Party then establishes outgoing OVR call to C-Party32 Figure 12 - OVR call from A-party to B-Party, OVR call is rejected ...................................................... 33 Figure 13 – OVR call from A-party to B-Party that exceeds B’s max OVR call limit, results in a 2-party

call for call duration ................................................................................................................ 33 Figure 14 - OVR call from A to B while B has outgoing OVR call established with C, and C with D.

OVR call from D to A will cause loop in audio chain.............................................................. 34 Figure 15 - OVR call from A party to B party while B has radio sessions with f1 and f2 ...................... 34 Figure 16 – Conference URI (focus) resource request ......................................................................... 36 Figure 17 – Session between UA A and B, CF not involved................................................................. 37 Figure 18 – Message flow, UA A requests focus .................................................................................. 37 Figure 19 – Session between UA A and UA B, B is conference focus (CF) ......................................... 38 Figure 20 – Message flow, focus hosted by UA A ................................................................................ 38 Figure 21 –UA A has requested focus .................................................................................................. 39 Figure 22 – Message flow, UA A requests focus to invite B ................................................................. 39 Figure 23 – UA A and B have conference at focus ............................................................................... 40 Figure 24 - Message flow, UA A requests focus to invite C .................................................................. 40 Figure 25 – Three party conference with focus..................................................................................... 41 Figure 26 – Priority call answered after releasing resources ................................................................ 43 Figure 27 – Priority call intrusion to a single call ................................................................................... 44 Figure 28 – Intrusion to Conference...................................................................................................... 44 Figure 29 – Automatic Priority call intrusion with T1 = 0 ....................................................................... 45 Figure 30 – Priority Call Intrusion Forbidden by Wanted User.............................................................. 45 Figure 31 – Priority Call Intrusion into another Priority Call Forbidden ................................................. 46 Figure 32 – Call Clearing by Intruder Party ........................................................................................... 46 Figure 33 – Call Clearing by Intruded Party .......................................................................................... 47 Figure 34 – Call Clearing by Other (‘Unwanted’) Party ......................................................................... 47 Figure 35 – Call Clearing Request by a Conference Focus.................................................................. 48

© EUROCAE, 2012

v

© EUROCAE, 2012

TABLE INDEX Table 1 – Supported Requests................................................................................................................ 8 Table 2 – SIP UA Request Header Fields............................................................................................. 10 Table 3 – Mapping between Requests and UA Response Header Fields............................................ 11 Table 4 – REGISTRAR Request Header Fields ................................................................................... 12 Table 5 – Mapping between Requests and REGISTRAR Response Header Fields............................ 13 Table 6 – Priority Header Field Values.................................................................................................. 13 Table 7 – Subject Header Field Values................................................................................................. 13 Table 8 – Supported SDP Types and Parameters................................................................................ 15 Table 9 – Audible Tones Generated by SIP Ends ................................................................................ 51

1

CHAPTER 1

INTRODUCTION

1.1 BACKGROUND

Ground-Ground (G-G) ATM voice systems have been based upon analogue and more recently, digital Time Division Multiplexing / Pulsed Code Modulation (TDM/PCM) technologies for many years. Nowadays, however, convergence of voice and data into one multimedia network is a popular trend with a variety of technical solutions available on the market. Following in this direction ATM communication networks are adopting, by a process of gradual evolution, a common infrastructure for voice and data services. As the technology has developed IP Technology has now the true potential to fulfil operational and technical ATM communication requirements - including those of voice / data convergence, Quality of Services (QoS), security and safety. There is also the possibility that IP may deliver solutions that will, over time, bring about true savings in investment and operating costs. EUROCAE Working Group 67 (WG-67) undertook the mission to assess the feasibility of using Voice over Internet Protocol (VoIP) for providing ATM voice services. The group defined criteria, requirements and guidelines based upon the following operational needs and constraints: • Operational and Technical Air-Ground (A-G) and Ground-Ground (G-G) ATM

Voice system requirements; • Existing IP Voice protocols and signalling standards; • IP network capabilities for Voice services; • Security, Quality of Service (QoS), and Convergence (infrastructure, protocol,

applications); • Existing IP Voice ATM system capabilities and service interfaces. The following tasks were identified to fulfil the WG-67 mission: • Define ATM Systems and identify their components (Voice Communication

System / VCS, Ground-based Radio Station / GRS) • Determine possible additional operational and technical ATM requirements for

new ATM voice systems, also taking into consideration A-G communications. • Make recommendations to upgrade current standardisation documents. • Develop a Technical Specification for a VoIP Voice ATM System including:

o Minimum performance and safety/security requirements for the system and, if appropriate, for components;

o Interoperability requirements between IP components of the VoIP ATM system;

o Minimum performance requirements of an IP Network to support ATM Voice services.

Consequently the following three documents were delivered: ED-136 - VoIP ATM System Operational and Technical Requirements ED-137 - Interoperability Standards for VoIP ATM Components ED-138 - Network Requirements and Performances for VoIP ATM Systems

© EUROCAE, 2012

2

The contents of all three documents are premised on the “Vienna Agreement” which defines the different components of a VoIP ATM system and their mutual interfaces as depicted in Figure 1.

FIGURE 1: VIENNA AGREEMENT

VoIP components are interconnected through an IP network and suppliers are free to define their internal architecture (IP/Ethernet, TDM/PCM - Time Division Multiplexing/Pulsed Code Modulation, etc.) Between VoIP components, required interfaces are defined to guarantee their functional and technical interoperability. Therefore, VoIP ATM Systems are composed of: • VoIP VCS Components performing Radio and / or Telephone functions,

including: 1. Controller Working Positions, assuring HMI including voice devices

(microphone and loudspeaker); 2. Possible local VCS Maintenance and Configuration stations; 3. Possible local Recording devices; 4. Possible LAN for local interconnection; 5. Possible Media Gateways to legacy systems (ATS-QSIG, ATS-R2, ATS-

No.5, PSTN, Radio analogue lines, etc.) • VoIP Ground Radio Station Components performing DSB-AM VHF and UHF

Radio functions. • VoIP Supervision System Components performing monitoring and control

functions. • VoIP Recording Components performing recording functions. • IP WAN Components performing interconnection services between two or

more different

© EUROCAE, 2012

3

1.2 ED-137 VOLUME 2 PRESENTATION

The scope of the WG67 ED-137 Documents is to define the rules for VoIP implementations to support ATM communications: • Radio for the Volume 1 • Telephone for the Volume 2 • European Legacy Telephone Interworking for the Volume 3 • Recording for the Volume 4 • Supervision for the Volume 5 This includes the performances requested for the related communications. The present document, ED-137 Volume 2, proposes a profile standard for the use of SIP to establish, terminate and modify speech media sessions of the Ground Telephone Service in an Air Traffic Services Ground Voice Network (AGVN). SIP is an application layer protocol for establishing, terminating and modifying multimedia sessions. It is typically carried over the Internet Protocol (IP) (RFC 791 [2] and RFC 2460 [6]). Telephone calls are considered as a type of multimedia session where just audio is exchanged. SIP is defined in RFC 3261 [8]. This document specifies the signalling profile both for basic services that provide a bi-directional transfer capability for speech media between user terminals in an IP AGVN employing SIP, and for call-related signalling in support of ATS supplementary services. Interworking between an IP AGVN and a public IP network is out of scope of this document.

1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS AND OPTIONS

The terminology for requirements, recommendations and options in this document is based on RFC 2119 [5], which specifies Best Current Practice regarding the use of Key Words for the Internet Community. As such, the following terminology is applied: • The word SHALL denotes a mandatory requirement; • The word SHOULD denotes a recommendation; • The word MAY denotes an option. To avoid confusion with their natural meanings in the English language, the words SHALL, SHOULD, and MAY take on the meaning stated above only where printed in boldface. When printed in normal (Arial) typeface, the natural English meaning is meant. Detailed description of terminology: 1. SHALL: This word has the same meaning as the phrase "REQUIRED"

and means that the definition is an absolute requirement of the specification.

2. SHALL NOT: This phrase means that the definition is an absolute prohibition of the specification.

3. SHOULD: This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

5. MAY: This word, or the adjective „OPTIONAL“, means that an item is truly optional.

© EUROCAE, 2012

4


The present document, ED-137 Volume 2, SHALL be referenced as phone.01 in the WG67-Version SIP header field as described in 3.4.9.

© EUROCAE, 2012

5

CHAPTER 2

COMMUNICATION MODEL

2.1 DEFINITIONS

The following terms are used in this document: • Gateway: An entity that performs interworking between a circuit-switched

AGVN employing legacy trunk signaling and an IP AGVN employing SIP. It also acts as a Media Gateway that terminates circuit-switched AGVN facilities (trunks, loops), packetizes the media stream and delivers packetized traffic to the IP AGVN. It performs these functions in the reverse order for media streams flowing from the IP AGVN to the circuit-switched AGVN.

• Incoming Gateway: A gateway that routes an incoming call from a route employing legacy trunk signalling to an IP network employing the SIP signalling system.

• Outgoing Gateway: A gateway that routes an outgoing call from an IP network employing the SIP signalling system onto a route employing legacy trunk signalling.

• SIP: SIP is the session initiation protocol defined by the IETF in RFC 3261 [8]. It defines the control messages to create and terminate communications sessions between multiple endpoints on IP networks.

• SIP Headers: SIP Headers are a set of parameters that could be assigned specific values inside a SIP message. They convey information about the SIP request or response.

• SIP Messages: SIP Messages are the basic language elements in SIP. Each SIP message contains SIP headers and may contain a message body. There are two types of SIP Messages: Request and Response.

• SIP Network Entity: A SIP Network Entity is any network component that supports SIP signalling.

• SIP Profiles: Profiles in SIP define headers to be used as well and values restrictions and definitions. It also defines which SIP Internet Draft to use and how to use them. Profiles may be defined by any organization. This document defines one of such profiles.

• SIP Request Methods: SIP Request Methods are messages, typically, sent by the SIP client to initiate a transaction. For example, an INVITE method starts a new call. A CANCEL method cancels the request.

• SIP Responses: SIP Responses are messages received by the SIP client during a transaction that was initiated by a request. One or more responses can take place in answer to a single request.

• User Agent Client: A User Agent Client (UAC) is the logical entity within each network component that creates new requests.

• User Agent Server: A User Agent Server (UAS) is the logical entity within each network component that generates a response to a SIP request.

2.2 PROTOCOL STACK

The specifications provided hereafter SHALL concern the interface between two VCSs for the following subjects: • Signalling • Audio

All requirements in this document can be met among others by corresponding IETF RFCs, ITU recommendations, ECMA standards and Eurocontrol specifications and recommendations, as indicated in each case.

© EUROCAE, 2012

6

2.2.1 Signalling in an IP AGVN

Signalling in an IP AGVN SHALL be based on the Session Initiation Protocol (SIP) (RFC 3261, [8]). SIP is an application-layer transaction protocol that provides signalling and control functionality for multimedia communications. SIP is an essential component in the context of other protocols to enable communication architectures. In addition to the signalling functionality specified in this document, it is assumed that the IP AGVN components also include the following functionality: • one or more physical interfaces on the IP network side supporting, through layer

1 and layer 2 protocols, IP as the network layer protocol and UDP (RFC 768 [1]) and TCP (RFC 793 [3]) as transport layer protocols, these being used for the transport of SIP signalling messages and, in the case of UDP, also for media information;

• the support of TLS (RFC 4346 [25]) as additional transport layer secure protocol on the IP network side, this being used for the transport of SIP signalling messages; and

• a means of transferring media information.

2.2.2 Audio Specifications

The audio transport SHALL be supported by the real-time transport protocol (RTP) (RFC 3550 [15]), and SHOULD be augmented by its associated control protocol (RTCP) to allow monitoring of the audio packets delivery. The voice SHALL be coded in accordance with ITU-T Rec. G711 A-law (in Europe) or µ-law (in USA/Japan) coding. If compression is needed ITU-T Rec. G.726, G.729, or G728 without Packet Loss Concealment MAY be used.

© EUROCAE, 2012

7

CHAPTER 3

PROFILE STANDARD FOR THE USE OF SIP IN AN AGVN

An Air Traffic Services VoIP Communications System SHALL support SIP version 2 as specified in RFC 3261 [8]. The requirements of RFC 3261 [8] SHALL apply with modifications as specified in the following sections.

3.1 LOGICAL SIP ENTITIES

3.1.1 User Agents

User Agents in an IP AGVN SHALL support the following services and procedures: 1. Registration

1.1. Registration Discovery 1.1.1. Configured registrar address (RFC 3261 [8], section 10.2.6) 1.1.2. Using address-of-record (RFC 3261 [8], section 10.2.6)

1.2. Adding Bindings (RFC 3261 [8], section 10.2.1) 1.3. Removing Bindings (RFC 3261 [8], section 10.2.2) 1.4. Refreshing Bindings (RFC 3261 [8], section 10.2.4) 1.5. Querying Bindings (RFC 3261 [8], section 10.2.1) 1.6. Ordering contacts (RFC 3261 [8], section 10.2.1.2)

2. Call Control 2.1. Establishing a session

2.1.1. UAC procedures (RFC 3261 [8], section 13.2) 2.1.2. UAS procedures (RFC 3261 [8], section 13.3) 2.1.3. Based on Location server messages (RFC 3261 [8], section

8.1.3.4) 2.2. Terminating a session with BYE

2.2.1. UAC procedures (RFC 3261 [8], section 15.1.1) 2.2.2. UAS procedures (RFC 3261 [8], section 15.1.2)

2.3. Cancelling a session 2.3.1. UAC procedures (RFC 3261 [8], section 9.1) 2.3.2. UAS procedures (RFC 3261 [8], section 9.2)

3. Querying for capabilities 3.1. Asking for capabilities (RFC 3261 [8], section 11) 3.2. Answering to a capabilities query (RFC 3261 [8], section 11)

3.1.2 Registrar

Registrars in an IP AGVN SHALL support the following services and procedures: 1. Registration

1.1. Maintaining Bindings (RFC 3261 [8], section 10.3) 1.2. Ordering contacts (RFC 3261 [8], section 10.2.1.2) 1.3. Unicast Registration (RFC 3261 [8], section 10.3)

© EUROCAE, 2012

8

3.1.3 Proxy Server

SIP Proxy Servers in an IP AGVN SHALL support the following services and procedures: 1. Call Control

1.1. Establishment of a session 1.1.1. Statefull procedures (RFC 3261 [8], sections 16 and 8.2) 1.1.2. Based on Location server messages (RFC 3261 [8], sections 16

and 8.2) 1.2. Terminating a session with BYE

1.2.1. Statefull procedures (RFC 3261 [8], sections 16 and 8.2) 1.3. Cancelling a session

1.3.1. Statefull procedures (RFC 3261 [8], sections 16 and 8.2) 2. Querying for capabilities

2.1. Answering to a capabilities query (RFC 3261 [8], section 11)

3.1.4 Redirect Server

Redirect Servers in an IP AGVN SHALL support the Redirection service as specified in RFC 3261 [8], section 8.3.

3.2 SUPPORTED REQUESTS

Logical SIP entities in an IP AGVN SHALL support requests (methods) indicated in Table 1.

Logical SIP Entity

User Agents Registrar Proxy Server Redirect Server Method Support Sending

Support Receiving

Support Sending

Support Receiving

Support Sending

Support Forwarding

Support Sending

Support Receiving

INVITE (RFC 3261 [8])

M m x n/a m m x m

ACK (RFC 3261 [8])

M m x n/a m m x n/a

CANCEL (RFC 3261 [8])

M m x n/a m m x m

BYE (RFC 3261 [8])

M m x n/a m m x m

REGISTER (RFC 3261 [8])

M n/a x m x m x n/a

OPTIONS (RFC 3261 [8])

M m x n/a x m x m

SUBSCRIBE (RFC 3265 [10])

O o x n/a x m x n/a

NOTIFY (RFC 3265 [10])

O o x n/a x m x n/a

REFER (RFC 3515 [14])

M m x n/a x m x n/a

INFO (RFC 2976 [7])

M m x n/a x m x n/a

MESSAGE (RFC 3428 [13])

O m x n/a x m x n/a

m: mandatory; o: optional; x: prohibited; n/a: not applicable

TABLE 1 – SUPPORTED REQUESTS

The requirements of RFC 3261 [8], RFC 2976 [7], RFC 3265 [10], RFC 3428 [13] and RFC 3515 [14] SHALL apply with modifications as specified in the following sub-

© EUROCAE, 2012

9

clauses.

3.2.1 INVITE and RE-INVITE

The INVITE request message SHALL always be sent by a User Agent Client at a VCS endpoint towards a User Agent Server at another VCS endpoint to request SIP session establishment. The INVITE request SHALL include an SDP body defining media information of the VCS endpoints. Once a session has been established, it is possible for a User Agent at a VCS endpoint to modify SDP parameters etc (i.e. codec, call types, etc.) and RTP receiving address ports through the use of a new INVITE request message within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE request message.

3.3 SUPPORTED RESPONSES

Logical SIP entities in an IP AGVN SHALL support the reception of all 1xx Provisional Responses, 2xx Successful Responses, 3xx Redirection Responses, 4xx Request Failure Responses, 5xx Server Error Responses and 6xx Global Failure Responses, as defined in RFC 3261 [8].

3.4 SUPPORTED HEADER FIELDS

The requirements of RFC 3261 [8], RFC 2976 [7], RFC 3265 [10], RFC3326 [11], RFC 3428 [12], RFC 3515 [13], RFC 3891 [21] and RFC3911 [22] SHALL apply with modifications as specified in the following sub-clauses. As indicated in RFC 3261 [8], header field values and parameter values SHALL be case-insensitive. Table 2, Table 3, Table 4 and Table 5 compile and summarize the minimum set of header fields that SHALL be supported in requests and responses. NOTE 1. According to the indicated RFCs, all the mandatory header fields appear as

mandatory in the tables. Besides, Content-Length, Priority and Subject header fields (indicated as optional in the RFCs) appear here as mandatory for specific requests; this is indicated by an ‘m’ in bold face type.

3.4.1 User Agent Request Headers

SIP UAs in an IP AGVN SHALL be capable of sending and receiving the SIP request header fields indicated in Table 2. SIP Proxy Servers in an IP AGVN SHALL be capable of receiving the SIP request header fields indicated in Table 2.

Requests UA Request Header Field ACK BYE CAN INF INV MES NOT OPT REF REG SUB

Accept --- o --- o o --- o m o o o Allow --- o --- --- o o o o o o o Allow-Events (RFC 3265 [10])

o o --- --- o --- o o --- o o

Authorization o o o o o o o o o o o Call-ID m m m m m m m m m m m Contact o --- --- o m --- m o m o m Content-Length m m m m m m m m o m m Content-Type * * --- * * * * * * * * Cseq m m m m m m m m m m m Date o o o o o o o o o o o Event (RFC 3265 [10])

--- --- --- --- --- --- m --- --- --- m

Expires --- --- --- o o o --- --- o o o From m m m m m m m m m m m In-Reply-to --- --- --- --- o o --- --- --- --- --- Join (RFC 3911 [23])

--- --- --- --- o --- --- --- --- --- ---

Max-Forwards m m m m m m m m m m m

© EUROCAE, 2012

10

Requests UA Request Header Field ACK BYE CAN INF INV MES NOT OPT REF REG SUB

MIME-Version o o --- --- o --- o o o o o Priority --- --- --- o m o --- --- --- --- o Proxy-Authorization o o --- o o o o o o o o Proxy-Require --- o --- o o o o o o o o Reason --- o o --- --- --- o --- --- -- --- Record-Route o o o o o --- o o o --- o Refer-To (RFC 3515)

--- --- --- --- --- --- --- --- o --- ---

Replaces (RFC 3891 [22])

--- --- --- --- o --- --- --- --- --- ---

Reply-to --- --- --- --- o o --- --- --- --- --- Require --- c --- --- c c o c c c o Route c c c o c o c c c c c Subject --- --- --- o m o --- --- --- --- --- Subscription-State (RFC 3265 [10])

--- --- --- --- --- --- m --- --- --- ---

Supported --- o o --- m* --- o o o o o To m m m m m m m m m m m Via m m m m m m m m m m m WG67-Version m m m m m m m m m m m

c: conditional m: mandatory m*: header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field o: optional ---: not applicable (i.e. header should not be

included in the request) * : required if message body is not empty

CAN: CANCEL INF: INFO INV: INVITE MES: MESSAGE NOT: NOTIFY OPT: OPTIONS

REF: REFER REG: REGISTER SUB: SUBSCRIBE

TABLE 2 – SIP UA REQUEST HEADER FIELDS

3.4.2 User Agent Response Headers

The Status Code column in Table 3 indicates the status code for which a given header may be included in the response. The columns that correspond to the request methods, indicate whether a given header field may (o) or shall (m) be used in a response to that particular type of request. SIP UAs in an IP AGVN SHALL be capable of sending and receiving the SIP response header fields indicated in Table 3. SIP Proxy Servers in an IP AGVN SHALL be capable of receiving the SIP response header fields indicated in Table 3.

Requests UA Response Header Field

Status Code ACK BYE CAN INF INV MES NOT OPT REF REG SUB

Accept 2xx --- --- --- --- o --- --- m* --- o --- Accept 415 --- c --- --- c m o c c c o Accept-Encoding

2xx --- --- --- --- o --- -- m* --- o ---

Accept-Encoding

415 --- c --- --- c m o c c c o

Accept-Language

2xx --- --- --- --- o --- --- m* --- o ---

Accept-Language

415 --- c --- --- c m o c c c o

Allow 2xx --- o --- --- m* o o m* --- o o Allow 405 --- m --- o m m m m m m m

© EUROCAE, 2012

11

Requests UA Response Status Header Field Code ACK BYE CAN INF INV MES NOT OPT REF REG SUB

Allow All except 2xx,405

--- o --- --- o o o o o o o


2xx o o --- --- o --- o o --- o o


489 --- --- --- --- --- --- m --- --- --- m

Authentication-Info

2xx --- o --- --- o o o o o o o

Call-ID All m m m m m m m m m m m Contact 1xx --- --- --- --- o --- o --- --- --- o Contact 2xx --- --- --- --- m --- o o m o m Contact 3xx --- o --- --- o o m o --- o m Contact 485 --- o --- --- o o o o o o o Content-Length

All m m m m m m m m o m m

Content-Type All * * --- * * * * * * * * Cseq All m m m m m m m m m m m Date All o o o o o o o o o o o Expires 2xx --- --- --- o o --- --- --- --- o --- From All m m m m m m m m m m m MIME-Version All o o --- --- o --- o o o o o Min-Expires 423 --- --- --- --- --- --- --- --- --- m m Proxy-Authenticate

407 --- m --- o m m m m m m m

Proxy-Authenticate

401 --- o o --- o o --- o o o ---

Reason 3xx,4xx, 6xx

--- --- --- o --- -- o o

Record-Route 18x o o o --- o --- --- o o --- --- Record-Route 2xx o o o o o --- --- o o --- --- Record-Route 401,484 --- --- --- --- --- --- o --- --- --- o Reply-To All --- --- --- --- o o --- --- --- --- --- Require All --- c --- --- c c o c c c o Supported 2xx --- o o --- m* --- o m* o o o To All m m m m m m m m m m m Unsupported 420 --- m --- o m o o m o m o Via All m m m m m m m m m m m Warning All --- o o o o o o o o o o WWW-Authenticate

401 --- m --- o m m m m m m m

WWW-Authenticate

407 --- o --- --- o o --- o o o ---

WG67-Version All m m m m m m m m m o m c: conditional m: mandatory m*: header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field o: optional ---: not applicable (i.e. header should not be

included in the response) * : required if message body is not empty

CAN: CANCEL INF: INFO INV: INVITE MES: MESSAGE NOT: NOTIFY OPT: OPTIONS

REF: REFER REG: REGISTER SUB: SUBSCRIBE

TABLE 3 – MAPPING BETWEEN REQUESTS AND UA RESPONSE HEADER FIELDS

© EUROCAE, 2012

12

3.4.3 Registrar Server Request Headers

The Registrar Server in an IP AGVN SHALL be capable of receiving the SIP request header fields indicated in Table 4.

Request REGISTRAR Request Header Field REGISTER Allow o Authorization o Call-ID m Contact m Content-Length m Content-Type * Cseq m Date o Expires m From m Max-Forwards o MIME-Version o Proxy-Authorization o Proxy-Require o Require m Route m Supported o To m Via m WG67-Version m

m: mandatory; o: optional; *: required if message body is not empty

TABLE 4 – REGISTRAR REQUEST HEADER FIELDS

3.4.4 Registrar Server Response Headers

Registrar Servers in an IP AGVN SHALL be capable of sending the SIP response header fields indicated in Table 5.

Request REGISTRAR Response Header

Field Status Code REGISTER

Allow 2xx o Authentication-Info 2xx o Call-ID 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Contact 2xx m Contact 3xx m Content-Length 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Content-Type 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 o Cseq 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Date 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 o Expires 2xx o From 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Min-Expires 423 o MIME-Version 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 o Proxy-Authenticate 407 o Proxy-Authenticate 401 m Require 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Supported 2xx o Unsupported 400, 401, 403, 404, 406, 407, 423 o To 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Via 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 m Warning 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 o

© EUROCAE, 2012

13

Request REGISTRAR Status Code Response Header REGISTERField

WWW-Authenticate 401 m WWW-Authenticate 407 o WG67-Version 2xx, 300, 400, 401, 403, 404, 406, 407, 423, 500, 503 o

m: mandatory; o: optional

TABLE 5 – MAPPING BETWEEN REQUESTS AND REGISTRAR RESPONSE HEADER FIELDS

3.4.5 Max-Forwards

A VCS SHOULD provide a management means of configuring the acceptable (network dependent) Max-Forwards initial value. Unless otherwise stated, the initial value for the Max-Forwards header field SHOULD be 70 as recommended in the RFC 3261 [8].

3.4.6 Priority

The Priority header field SHALL take one from the values in Table 6. In case of the Priority header field is not included in a request or takes a different value to those in Table 6, it SHALL be assumed as “non-urgent”.

Type of call SIP Priority header field value Priority Priority Direct / Indirect Access call emergency

Instantaneous Access call urgent Tactical Direct / Indirect Access call urgent Strategic Direct / Indirect Access call normal Routine General Purpose Direct / Indirect Access call non-urgent

Monitoring Position monitoring non-urgent

TABLE 6 – PRIORITY HEADER FIELD VALUES

3.4.7 Subject

The Subject header field SHALL take one from the values in Table 7. In case of the Subject header field takes value “Radio” or “Radio call”, the call SHALL be rejected. In other cases, should the Subject header field be not included in a request or take a different value to those in Table 7, it SHALL be assumed as “DA/IDA call”.

Type of call SIP Subject header field value Instantaneous Access call IA call Priority Direct / Indirect Access call DA/IDA call Routine Direct / Indirect Access call DA/IDA call Position monitoring (combined A/G and G/G) monitoring Position monitoring (A/G only) A/G monitoring Position monitoring (G/G only) G/G monitoring

TABLE 7 – SUBJECT HEADER FIELD VALUES

© EUROCAE, 2012

14

3.4.8 Reason

The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. The syntax of the header field follows the standard SIP parameter syntax as defined in RFC 3326 [11] and SHALL have the following content: Reason = "Reason" HCOLON reason-value *(COMMA reason-value) reason-value = protocol *(SEMI reason-params) protocol = "WG-67" reason-params = protocol-cause / reason-text / reason-extension protocol-cause = "cause" EQUAL cause_phone / cause_radio cause_phone = 1000-1099 cause_radio = 2000-2099 reason-text = "text" EQUAL quoted-string reason-extension = generic-param Cause values for the protocol type WG-67 SHALL be in the range from 1000 to 1099 for telephone applications and from 2000 to 2099 for radio applications. Examples are:

Reason: WG-67; cause=1001; text=”Emergency - Forced Release” Reason: WG-67; cause=2001; text=”Missing R2S-keepalive”

NOTE 2. Other cause values and the corresponding reason text are given where applicable.

3.4.9 WG67-Version

The WG67-Version header field SHALL appear in any request and in any response, but SIP elements need to be prepared to receive messages without that header field indicating implementations based on earlier WG-67 EDs. The syntax of the header field follows the standard SIP parameter syntax as defined in RFC 3261 [8] and SHALL have the following content:

WG67-Version = “WG67-Version” HCOLON version-value *(COMMA version-value) version-value = field-value *(SEMI version-params) field-value = type “.” number type = “radio” / “phone” / “legacy-eu” / “recorder” / “supervision” number = 2*DIGIT

The field-value SHALL contain the latest document version that reflects the implemented version of the corresponding ED as listed in section 1.4 VERSION TRACKING. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. According actions MAY be specified where applicable. Examples are:

WG67-Version: phone.01 WG67-Version: phone.03,legacy-eu.01 WG67-Version: legacy-eu.01; gateway=”ATS-R2”

NOTE 3. version-params may be used for future extensions and are not described further in this document. The given example covers a possible scenario, where a VCS may support different document versions for different legacy gateway types, therefore a parameter may be used as differentiator e.g. legacy-eu.01; gateway=”ATS-R2” and legacy-eu.02; gateway=”ATS-QSIG”.

© EUROCAE, 2012

15

3.5 MESSAGE BODY

SIP message bodies containing a description of the session, time and media SHALL be encoded in the Session Description Protocol (SDP) (RFC 4566 [26]). The SDP types and parameters indicated in Table 8 SHALL be supported. SDP parameters and values SHALL be interpreted as being case sensitive. SIP message bodies containing conference state data SHALL be encoded according to the SIP Event Package for Conference State (RFC 4575 [27]). SIP message bodies containing presence information data SHALL be encoded in the Presence Information Data Format (PIDF) (RFC 3863 [21]), according to the Presence Event Package for the Session Initiation Protocol (RFC 3856 [20]). SIP message bodies containing mid-call messages SHALL be encoded in the Text/Plain Format (RFC 3676 [18])

Description SDP Types SDP Parameters Values Protocol version (“v=”) <SDP version number> 0

<username> (Application dependent) <sess-id> (Application dependent) <sess-version> (Application dependent) <nettype> IN <addrtype> IP4 (in the interim)

IP6

Origin (“o=”)

<unicast-address> (Application dependent) Session name (“s=”) <session name> (Application dependent)

<nettype> IN <addrtype> IP4 (in the interim)

IP6

Session

Connection data (“c=”)

<connection-address> (Application dependent) <start-time> (Application dependent) Time Timing (“t=”) <stop-time> (Application dependent) <media> audio <port> (Application dependent) <proto> RTP/AVP

Media descriptions (“m=”) <fmt> 0 (for PCM-μ) 8 (for PCM-A) 15 (for G.728) 18 (for G.729)

<send-receive mode> recvonly sendrecv sendonly inactive

Media

Attributes (“a=”) rtpmap:<payload type> <encoding name>/<clock rate> (optional)

PCMU/8000 (for PCM-μ) PCMA/8000 (for PCM-A) G728/8000 (for G.728) G729/8000 (for G.729)

fmtp:15 sendsync (optional)

(ATS-QSIG/SIP Gateway specific)

a=sid:<unique node id> (optional)

(Application dependent)

a=rid:<unique node id> (optional)

(Application dependent)

a=service:<type> (optional)

simplex duplex limited

TABLE 8 – SUPPORTED SDP TYPES AND PARAMETERS

© EUROCAE, 2012

16

3.6 ADDRESS FORMAT

As specified in RFC 3261 [8], the formal syntax for a SIP and SIPS URI is: SIP-URI = “sip:” [ userinfo ] host [ “:” port ] uri-parameters [ headers ] SIPS-URI = “sips:” [ userinfo ] host [ “:” port ] uri-parameters [ headers ] where <userinfo> SHALL be coded as: userinfo = ( ATS_telephone_number / user_role) ”@” ATS_telephone_number = 1*DIGIT user_role = 1* (unreserved) Besides, the <host> part SHOULD be coded as: host = atsu ”.” centre_id ”.” local_domain atsu = 1* (unreserved) centre_id = 4*ALPHA; /*ICAO identifier for a specific ATS centre local_domain = 1* (unreserved); /*ANSP domain Examples are: sip:314002@en_route.lecm.es.net sip:planner.zmu@en_route.lecm.es.net

3.7 SECURITY REQUIREMENTS

Logical SIP entities in an IP AGVN SHALL support HTTP Authentication with the “Digest” authentication mechanism using the following parameters: 1. digest-uri 2. nonce 3. realm 4. response 5. username Besides, logical SIP entities in an IP AGVN SHOULD support the following additional Security capabilities: 1. S/MIME (Secure / Multipurpose Internet Mail Extensions) 2. TLS (Transport Layer Secure) protocol

© EUROCAE, 2012

17

CHAPTER 4

GROUND TELEPHONE FACILITIES

4.1 ROUTINE DIRECT/INDIRECT ACCESS CALL

The Direct Access (DA) facility enables a user to initiate a call by operating on a single key; whereas the Indirect Access (IDA) facility enables a user to enter a complete address on a telephone dialling keypad (or equivalent device) in order to cause a call attempt to be made to the supplied address, this is equivalent to normal dialled telephone operation. The establishment and clearing of a Routine (Non-priority) DA/IDA call SHALL be handled as specified in RFC 3261 [8] and RFC 3665 [16]. The INVITE request for a Routine DA/IDA call SHALL include the Priority header field with value “urgent”, “normal” or “non-urgent”, as indicated in Table 6, and the Subject header field with value “DA/IDA call”.

4.2 CALL PRIORITY

The Priority facility is a means of attaching an indicator to a DA/IDA telephone call to show that it is "emergency" as opposed to "routine". It is intended for use when it is necessary to make a call concerning the safety of aircraft (i.e., an emergency situation). In addition to the requirements of a Routine call, Priority DA/IDA calls imply execution of the Intrusion supplementary service as specified in sub-clause 4.9 below. The INVITE request for a Priority DA/IDA call SHALL include the Priority header field with value “emergency” and the Subject header field with value “DA/IDA call”.

4.3 INSTANTANEOUS ACCESS CALL

An "Instantaneous Access call" is a call with automatic call establishment that enables audio transmission from the calling party to the called party, without the called party having to perform any acceptance action at the called-party’s terminal. Once the IA call is established, the called party can also transmit to the calling party by activating his/her IA key. The Instantaneous Access call remains while there is at least one party transmitting to the other. In order to make an IA call, the calling party will activate the associated IA key on the IA panel at his/her terminal. The called party is informed of IA call arrival through a change in state of the corresponding IA key on the IA panel at his/her terminal. If the called party is already involved in an active call, the IA facility MAY establish a monitor-type connection between the calling party and the called party.

4.3.1 Application

An individual IA call MAY only take place exclusively on a point-to-point basis between two pre-defined parties, and the ‘System’ SHALL incorporate facilities to both establish and control this so as to ensure that the integrity of the call is never compromised.

4.3.2 Establishment Conditions

The IA Supplementary Service (SS-IA) must be available in the VCSs involved and corresponding IA keys must be configured on both user terminals. The called party may be free or involved in another active call (e.g. IA, Radio, DA/IDA routine or DA/IDA priority call); the actual status of the called party is irrelevant.

© EUROCAE, 2012

18

4.3.3 Audio

Once the IA call is established, if monitoring is enabled, the calling party MAY hear a combination of: • transmitted and/or received audio from any active DA/IDA telephone voice calls

at the called party’s CWP; and/or • transmitted and/or received audio from any other active IA calls at the called

party’s CWP; and/or • transmitted and/or received audio from any active radio voice calls at the called

party’s CWP; and/or • any other audio signal suitably injected in the audio path to the calling user. Such audio combination SHALL be configurable according to ANSP specific requirements, for the whole system or for specific user terminals. In any case, to prevent either echoing or audio feedback, VCS systems SHALL remove the calling party’s voice from the monitoring channel. The called party SHALL hear the audio transmitted by the calling party. Should the called party respond to the calling party, the calling party SHALL hear audio transmitted by the called party. In this case, since two sessions (A Ą B & B Ą A) coexist for a single IA call, VCS systems SHOULD remove the calling party’s voice and the called party’s voice from respective monitoring channels to avoid possible problems derived from the same audio coming to a party’s terminal through two different RTP paths.

4.3.4 Timing Constraints

The SS-IA SHALL meet the requirements of the Instantaneous Controller-Controller Voice Communication (ICCVC) which stipulates that communication be established between non-physically adjacent controllers within 1 second or less in 99% of the time.

4.3.5 IA Call Signalling Procedures

An IA call SHALL be handled as two independent sessions (A Ą B & B Ą A), each session SHALL be controlled by its creator. The initial session from A to B SHALL be controlled (released) by A and its possible response from B to A SHALL be controlled (released) by B. NOTE 4. From a SIP perspective, these two sessions are completely independent;

there is only a dependency within the application or Graphical User Interface.

A VoIP VCS implementing SIP SS-IA SHALL support the offer/answer model specified in RFC 3264 [9].

4.3.5.1 Actions at the Calling-party User Agent

To make an IA call, the Calling-party UA SHALL send an INVITE request, including a Priority header field with value “urgent” and a Subject header field with value “IA call”; it SHALL start timer T0. If the call fails for reasons other than those covered below, the Calling-party UA SHALL stop timer T0 and indicate “IA call failure” to the Calling-party. While awaiting IA call confirmation, a) if the calling party releases the IA call, the Calling-party UA SHALL send a

CANCEL request and stop timer T0; b) on receipt of a 200 (OK) final response, the Calling-party UA SHALL send an

ACK request and establish both-way RTP media, enable Calling-party’s Tx & Rx and stop timer T0; “IA-Tx: active, IA-Rx: monitoring-active” MAY be indicated on the appropriate IA key on the IA panel of the calling party’s terminal;

© EUROCAE, 2012

19

NOTE 5. At this point, a session has been created in which the voice path from the called party to calling party is used for monitoring Ground and Radio calls in progress at the called party’s terminal.

c) on receipt of a 200 (OK) final response containing an “a=recvonly” SDP answer attribute, the Calling-party UA SHALL send an ACK request and establish one-way RTP media, enable calling party’s Tx, stop timer T0 and enter state IA-Tx-Active; “IA-Tx: active, IA-Rx: non-active” MAY be indicated on the appropriate IA key on the IA panel of the calling party’s terminal;

NOTE 6. In this case, a session has been created without monitoring. d) on receipt of a 4xx-6xx final response, the Calling-party UA SHALL indicate “IA

call failure” to the calling party and stop timer T0; e) on expiry of timer T0, the Calling-party UA SHALL indicate “IA call failure” to the

calling party and send a CANCEL request. Once the IA call is established, a) if the calling party releases the IA transmission, the Calling-party UA SHALL

send a BYE request for its controlled session and disable the calling party’s Tx; “IA-Tx: non-active, IA-Rx: non-active”, or “IA-Tx: non-active, IA-Rx: active” MAY be indicated on the appropriate IA key on the IA panel of the calling party’s terminal, depending on the status of the non-controlled IA session.

4.3.5.2 Actions at a Proxy

No special actions are required in support of SIP SS-IA.

4.3.5.3 Actions at the Called-party User Agent

Upon receipt of an INVITE (Priority=“urgent”, Subject=“IA call”) request, the Called-party UA SHALL check if there is an application dependent cause to reject the IA call; 1. Should there be a cause for rejection, the Called-party UA SHALL send the

corresponding 4xx-6xx response; “Incoming call attempt” MAY be indicated on the appropriate IA key on the IA panel of the Called-party’s terminal;

2. otherwise, the Called-party UA SHALL immediately send a 200 (OK) response and enable the called party’s Rx; if monitoring is enabled, the Called-party UA SHALL establish a monitor type connection to the calling party (all Ground and Radio calls in progress at the called party’s terminal SHALL be monitored by the calling party), otherwise, an “a=recvonly” SDP attribute SHALL be included in the 200 (OK) response; “IA-Tx: non-active, IA-Rx: active” MAY be indicated on the appropriate IA key on the IA panel of the called party’s terminal.

Once the IA call is established, a) on receipt of a BYE request, the Called-party UA SHALL send 200 (OK) final

response and disable the called party’s Rx; “IA-Tx: non-active, IA-Rx: non-active”, or “IA-Tx: active, IA-Rx: non-active” MAY be indicated on the appropriate IA key on the IA panel of the called party’s terminal, depending on the status of the non-controlled IA session.

4.3.6 IA Call Parameter Values (Timers)

Timer T0 SHALL operate at the Calling-party UA during state IA-Awaiting-Confirmation. It SHALL be started on sending INVITE (Priority=“ urgent”, Subject=“IA call”) and stopped on receipt of 200 (OK) or 4xx-6xx final responses. Timer T0 SHOULD have a value of 2 seconds unless otherwise stated. NOTE 7. The timer T0 may be set to other values according to ANSP specific

requirements.


4.3.7.1 Interaction with the Call Priority Interruption Supplementary Service

An IA call SHALL NOT be interrupted.

4.3.7.2 Interaction with the Call Hold Supplementary Service

Call hold SHALL NOT be invoked for an IA call.

© EUROCAE, 2012

20

4.3.7.3 Interaction with the Call Transfer Supplementary Service

Call transfer SHALL NOT be invoked for an IA call.

4.3.7.4 Interaction with the Call Intrusion Supplementary Service

Intrusion SHALL NOT be invoked for an IA call; this means that the Priority header field included in an INVITE for an IA call SHALL always take value “urgent” and never “emergency”. NOTE 8. An IA call may monitor all active Ground (DA, IDA and IA) and Radio calls

at the called position before talking; anyway, this is not an intrusion because audio is not sent to remote unwanted users.

Besides, an IA call SHALL NOT be intruded by a DA/IDA Priority call.

4.3.8 IA Call Message Sequence Charts

The Message Sequence Charts (MSC) in figures below show the information flows between the Calling-party UA and the Called-party UA. Each information flow is named according to the corresponding message sent to or received from respective party. Dashed lines (---) represent SIP signalling messages that are mandatory to the call scenario. The arrow indicates the direction of message flow. Double dashed lines (===) represent media paths between network elements.

One-way voice path A-B connected to B’s ground telephne earpiece or loudspeaker. Voice path B-A used for monitoring Ground & Radio calls in progress.

A-party UA B-party UAProxy 1

INVITE (urgent, IA call)INVITE (urgent, IA call)

100 Trying100 Trying

Auto answer

Proxy 2

INVITE (urgent, IA call)

200 OK

Both-way RTP media

A ă B: monitoringA Ą B: talking

A activates IA key

A de-activates IA key

200 OK200 OK

ACKACK

ACK

BYEBYE

200 OK

BYE

200 OK200 OK

FIGURE 2: IA CALL FROM A-PARTY TO B-PARTY. IA CALL ESTABLISHED AND A-PARTY CLEARS CALL

© EUROCAE, 2012

21

One-way voice path A-B connected to B’s ground telephne earpiece or loudspeaker. Voice path B-A used for monitoring Ground & Radio calls in progress at B-partys’s terminal.

INVITE (urgent, IA call, ses1)INVITE (urgent, IA call, ses1)


Auto answer

INVITE (urgent, IA call, ses1)

200 OK

Both-way RTP media for the 1st session


A-party UA Proxy 1 Proxy 2 B-party UA

A activates IA key

B activates IA keyINVITE (urgent, IA call, ses2)


200 OK200 OK


200 OK


Both-way RTP media for the 2nd session

A ă B: talkingA Ą B: monitoring

Auto answer

200 OK200 OK

ACK ACKACK

ACKACK

ACK

One-way voice path B-A connected to A’s ground telephne earpiece or loudspeaker. Voice path A-B used for monitoring Ground & Radio calls in progress at A-party’s terminal.

FIGURE 3: IA CALL FROM A-PARTY TO B-PARTY. IA CALL ESTABLISHED, B-PARTY RESPONDS






200 OK

100 Trying

200 OK200 OK

100 Trying



Auto answer

ACKACK

ACK

A de-activates IA key BYE (ses1)BYE (ses1)

200 OK

BYE (ses1)

200 OK200 OK

FIGURE 4: IA CALL FROM A-PARTY TO B-PARTY. IA CALL ESTABLISHED, B-PARTY RESPONDS, THEN A-PARTY DE-ACTIVATES IA KEY

© EUROCAE, 2012

22



A-party UA Proxy 1



200 OKa=recvonly 200 OK

a=recvonly


200 OKa=recvonly

100 Trying100 TryingAuto answer

B de-activates IA keyBYE (ses2)BYE (ses2)

200 OK200 OK

BYE (ses2)

200 OK

ACKACK

ACK

Proxy 2

One-way RTP media for the 2nd session

A ă B: talking

B-party UA

In this example, monitoring is not configured on VCS “A”

FIGURE 5: MONITORING NOT CONFIGURED ON A-PARTY’S VCS. IA CALL FROM A-PARTY TO B-PARTY. IA CALL ESTABLISHED, B-PARTY RESPONDS, THEN

B-PARTY DE-ACTIVATES IA KEY

One-way RTP media for the 1st session

A Ą B: talking

A-party UA Proxy 1 B-party UA


200 OK

One-way RTP media for the 2nd session

A ă B: talking

Proxy 2

In this example, monitoring is not configured on VCS “A”

In this example, monitoring is not configured on VCS “B”

BYE (ses1)

200 OK200 OK


100 Trying

A re-activates IA key

100 Trying Auto answer


200 OKa=recvonly200 OK

a=recvonly200 OKa=recvonly

ACKACK

ACK

One-way RTP media for the 3rd session

A Ą B: talking

FIGURE 6: MONITORING NOT CONFIGURED ON BOTH VCSS. IA CALL FROM A-PARTY TO B-PARTY. IA CALL ESTABLISHED, A Ą B: TALKING & BĄ A:

TALKING, A-PARTY DE-ACTIVATES IA KEY AND THEN RE-ACTIVATES IA KEY

© EUROCAE, 2012

23







200 OK

BYE (ses1)

200 OK200 OK

B de-activates IA keyBYE (ses2)BYE (ses2)

200 OK

BYE (ses2)

200 OK200 OK

FIGURE 7: IA CALL FROM A-PARTY TO B-PARTY. IA CALL ESTABLISHED, A Ą B: TALKING & BĄ A: TALKING, A-PARTY DE-ACTIVATES IA KEY

AND B-PARTY DE-ACTIVATES IA KEY

INVITE (urgent, IA call)INVITE (urgent, IA call)


INVITE (urgent, IA call)

4xx


A activates IA key

4xx4xx ACK

ACKACK

IA call is rejected

FIGURE 8: IA CALL FROM A-PARTY TO B-PARTY. IA CALL IS REJECTED

© EUROCAE, 2012

24

4.4 OVERRIDE CALL

An override (OVR) call is a call that enables two-way audio transmission between calling party and the called party, without the called party having to perform any acceptance action at its operator position. In order to make an OVR call, the calling party will either activate the associated IA key on the IA panel at its terminal or enter the OVR call access code followed by the called party address via the Indirect Access (IDA) keypad at its terminal. The called party is informed of OVR call arrival through a change in state of the corresponding IA key on the IA panel at its operator position. On establishment of an incoming OVR call from the calling party, the called party places the calling party in a conference thereby allowing the calling party to hear audio from all active ground telephone calls and air-ground transmissions and receptions emanating from the called position, the audio from the called party microphone plus the audio of all Ground-Ground and Air-Ground communications directed to the called party position as a result of its own outgoing OVR call with another party etc. Likewise on arrival of an incoming OVR call from the calling party, the calling party shall send the called party the summed audio from all active ground telephone calls received at the calling position plus the audio from the calling party microphone. Audio from the called party headset microphone is always being sent to the calling party even in the case that there are no other active ground telephone or radio calls in progress at the called party side. It is not necessary for the called party to activate any key (as in the case of a European IA call). Likewise audio from the calling party headset microphone is always being sent to the called party even in the case that there are no other active ground telephone calls in progress at the calling party side. The OVR call remains connected until either the calling party or the called party clears the call by deselecting the associated IA key. NOTE 9. The Override call is similar to the Instantaneous Access call and can be

implemented by using the Instantaneous Access supplementary service as defined in section 4.3. The called party to an incoming OVR call will however always accept a two-way session by using the SDP “send-receive mode” attribute set to “a=sendrecv” and a new SDP “service” attribute set to “a=service: duplex”. The OVR call also introduces new SDP “a=sid” and “a=rid” attributes.

4.4.1 Establishment Conditions

The IA Supplementary Service (SS-IA) must be available in the VCSs involved. An ‘A’-party can make an OVR call to a ‘B’-party operator position without a pre-configured IA key present. The OVR call will be routed to a key in the Indirect Access call queue with a visual indication given for OVR call presence. The ‘B’-party may be free or involved in another active call (e.g. OVR, Radio, DA/IDA routine or DA/IDA priority call); the actual status of the ‘B’-party is irrelevant.

4.4.2 Audio

Once the OVR call is established at the 'B' party, because monitoring is always enabled, the 'A' party SHALL hear a combination of: • sent and/or received audio from any active incoming OVR telephone calls at the

'B' party (in the case that the 'B' party’s OVR selector switch is set to headset); and

• sent and/or received audio from any active incoming DA/IDA telephone calls at the 'B' party; and

• sent and/or received audio from any active outgoing OVR telephone call at the 'B' party to a ‘C’-party. The received audio may include combined G/G and A/G audio directed to the ‘B’ party from the ‘C’-party.

• transmitted audio from any active radio call at the 'B' party’s microphone; and • received audio from any active aircraft call at the 'B' party; and • any other audio signal suitably injected in the audio path to the 'A' party.

© EUROCAE, 2012

25

Once an OVR call from the ‘A’-party is established, the ‘B’-party SHALL hear a combination of: • sent and/or received audio from any active incoming OVR telephone calls at the

'A' party (in the case that the 'A' party’s OVR selector switch is set to headset); and

• sent and/or received audio from any active incoming DA/IDA telephone calls at the 'A' party; and

• any other audio signal suitably injected in the audio path to the 'B' party. In the case that the ‘A’-party has one or several incoming OVR calls established, the ‘B’-party SHALL also hear the summed audio from all of these parties with calls established to the ‘A’-party. The ‘B’-party SHALL NOT hear: • transmitted audio from any active radio call at the 'A' party’s microphone; and • received audio from any active aircraft call at the 'A' party In the case that the ‘B’-party has made its own OVR call to a ‘C’-party while there are already established incoming OVR calls at the ‘B’-party position, the ‘C’-party SHALL hear audio coming from any of the ‘B’-party’s incoming OVR calls. The ‘B’-party SHALL NOT transmit audio from any of the established OVR calls on its air-ground uplink. In order to prevent either echoing or audio feedback, VCS systems SHALL implement an audio loop detection method in order to avoid possible problems derived from the same audio coming to a party’s operator position through two different RTP paths. This audio loop detection method shall prevent a loop from occurring in a chain of OVR calls (see 4.4.6).

4.4.3 Timing Constraints

The SS-IA SHALL meet the ICAO 9804 defined requirements of the Instantaneous Controller-Controller Voice Communication (ICCVC) which stipulates that communication be established between non-physically adjacent controllers within 1 second or less in 99% of the time. NOTE 10. In the case of an OVR call a more stringent value than 1 second maximum

MAY be imposed.

4.4.4 OVR Call Signalling Procedures

The OVR call SHALL be handled as one session (A ↔ B) controlled by its creator. The OVR call session from ‘A’-party to ‘B’-party SHALL be released (cleared) either by the ‘A’-party or by the ‘B’-party. A VoIP VCS implementing SIP SS-IA SHALL support the offer/answer model specified in RFC 3264.

4.4.4.1 Actions at the Calling-party User Agent

To make an OVR call, the ‘A’-party User Agent SHALL send an INVITE request, including a Priority header field with value “urgent” and a Subject header field with value “IA call”; it SHALL start timer T0. The INVITE’s SDP message body SHALL contain an “a=sendrecv” SDP offer attribute and the SDP “a=service” attribute set to “a=service:duplex”. In addition, the offer SHALL contain the SDP “a=sid” attribute set to “a=sid:ID0 ID1 ID2 .. IDn” containing all established OVR call members. The identifier from call participants of incoming OVR calls SHALL be unique over space and time and listed as call participants source ID separated by a single SPACE character, forming the OVR tail.

© EUROCAE, 2012

26

NOTE 11. Each node shall provide an OVR tail and chain to its adjacent node. The tail comprises all nodes that form a branch terminating at the overridden node (‘B’-party). The chain comprises all nodes that form a branch originating from an overriding node (‘A’-party).

In general, a tail is being forwarded via INVITE and INFO messages containing the sending node identifier (ID0) and the sum of all tails connecting to this node (ID1 ID2 .. IDn) as list within the SDP attribute “a=sid:ID0 ID1 ID2 .. IDn”. The chain is being forwarded via 200 OK (as final response to the INVITE request) and INFO messages containing the sending node identifier (ID0) and the chain connecting to this node (ID1 ID2 .. IDn).

The SDP parameter “a=service:duplex” and “a=sid:ID0 ID1 ID2 .. IDn” are mandatory in INVITE, 200 OK and INFO SIP messages of an OVR call. If the call fails for reasons other than those covered below, the ‘A’-party UA SHALL stop timer T0 and indicate “OVR call failure” to the ‘A’-party. While awaiting OVR call confirmation, a) if the ‘A’-party releases the OVR call, the ‘A’-party UA SHALL send a CANCEL

request and stop timer T0; b) on receipt of a 200 OK final response containing “a=sendrecv”,

“a=service:duplex” and “a=sid:ID0 ID1 ID2 .. IDn” answer SDP attributes, the ‘A’-party UA SHALL send an ACK request and establish both-way RTP media, enable ‘A’-party’s Tx and Rx paths, stop timer T0 and enter state IA-Tx-Active; “IA-Tx: active, IA-Rx:active” MAY be indicated on the appropriate IA key on the IA panel of the ‘A’-party’s CWP;

NOTE 12. At this point, a session has been created in which the voice path from the ‘B’-party to ‘A’-party is used for monitoring audio of Ground and Radio calls in progress at the ‘B’-party’s CWP and for monitoring any audio at the ‘B’-party’s microphone even when there are no other Ground and Radio calls in progress at the ‘B’-party’s CWP.

The voice path from the ‘A’-party to ‘B’-party is used for sending summed audio of Ground calls in progress at the ‘A’-party’s CWP and for sending any audio at the ‘A’-party’s microphone even when there are no other Ground and Radio calls in progress at the ‘A’-party’s CWP.

c) on receipt of a 4xx-6xx final response, the ‘A’-party UA SHALL indicate “OVR call failure” to the ‘A’-party and stop timer T0;

d) on expiry of timer T0, the ‘A’-party UA SHALL indicate “OVR call failure” to the ‘A’-party and SHALL send a CANCEL request.

e) on receipt of a 200 OK final response containing “a=sendrecv”, “a=service:limited” and “a=sid:ID0 ID1 ID2 .. IDn” answer SDP attributes, the ‘A’-party UA SHALL send an ACK request and establish both-way RTP media, enable ‘A’-party’s Tx and Rx paths, stop timer T0 and enter state IA-Tx-Active; “IA-Tx: active, IA-Rx:active” MAY be indicated on the appropriate IA key on the IA panel of the ‘A’-party’s CWP; In this case the OVR call limit has been exceeded at the ‘B’-party, implying that only a simple 2-party call is established. The ‘A’-party SHALL take no action with respect to processing the sid attribute. The 2-party call remains until cleared.

Once the OVR call is established, a) the ‘A’-party SHALL send the Sum of ‘A’-party’s G/G audio plus the ‘A’-party

microphone audio (A∑G/G + A mic) to the ‘B’-party. If the ‘A’-party also has incoming OVR calls connected, it SHALL also add the G/G audio plus the microphone audio from each of the calling parties to the audio sum being sent to the ‘B’-party.

© EUROCAE, 2012

27

b) the ‘A’-party SHALL issue a SIP INFO message (text/plain) containing its updated chain to each established incoming OVR call (if any exist), in order to provide calling parties with updated information about its current audio connections (see 4.4.6). The summed audio stream being sent on the monitoring path to each calling party should reflect connections present in the chain originating from ‘A’-party.

c) should the ‘A’-party receive a SIP INFO message (text/plain) defining an update to the local chain of its ‘B’-party, it SHALL issue a SIP INFO message (text/plain) containing its own updated chain to each established incoming OVR call (if any exist) in order to provide calling parties updated information about its current audio connections (see 4.4.6). The summed audio stream being sent on the monitoring path to each calling party should reflect connections present in the chain originating from ‘A’-party.

d) should the ‘A’-party receive a SIP INFO message (text/plain) defining an update to the local tail of its calling parties, it SHALL issue a SIP INFO message (text/plain) containing its own updated tail to the established outgoing OVR call in order to provide the called party updated information about its current audio connections (see 4.4.6). The summed audio stream being sent to the called party should reflect connections present in the tail terminating at ‘A’-party.

e) if the ‘A’-party clears its outgoing OVR call, the ‘A’-party UA SHALL send a BYE request in order to clear the session. This SHALL be acknowledged by the ‘B’-party with a 200 OK final response.

f) if the ‘B’-party clears its incoming OVR call, the ‘B’-party UA SHALL send a BYE request in order to clear the session. This SHALL be acknowledged by the ‘A’-party with a 200 OK final response.

If a two-party call is established because the ‘B’ party OVR call limit has been exceeded, a) the ‘A’-party SHALL send the ‘A’-party’s microphone audio (A mic) to the ‘B’-

party. If the ‘A’-party also has incoming OVR calls connected, it SHALL also add the G/G audio plus the microphone audio from each of the calling parties to the audio sum being sent to the ‘B’-party.

b) the ‘A’-party SHALL include the received ‘B’-party microphone audio (B mic) with the summed audio stream being sent on the monitoring path to each of its calling parties.

Once the OVR call has been cleared by either the ‘A’-party or the ‘B’-party, a) the ‘A’-party SHALL issue a SIP INFO message (text/plain) containing its

updated chain to each of its established incoming OVR calls (if any exist), in order to provide calling parties updated information about its current audio connections (see 4.4.6). The summed audio stream being sent on the monitoring path to each calling party should reflect connections present in the chain originating from ‘A’-party.

4.4.4.2 Actions at a Proxy

No special actions are required in support of SIP SS-IA.

4.4.4.3 Actions at the Called-party User Agent

Upon receipt of an INVITE (Priority=“urgent”, Subject=“IA call”) request with an SDP message body containing the parameters “a=sendrecv”, “a=service:duplex” and “a=sid:ID0 ID1 ID2 .. IDn” as offer attributes, the ‘B’-party UA SHALL recognize this as an OVR call and check if there is an application dependent cause to reject the OVR call; 1. Should there be a cause for rejection, the ‘B’-party UA SHALL send the

corresponding 4xx-6xx response; “Incoming call attempt” MAY be indicated on the appropriate IA key on the IA panel of the ‘B’-party’s operator position;

© EUROCAE, 2012

28

2. Otherwise, the ‘B’-party UA SHALL immediately send a 100 Trying followed by 200 OK response containing the “a=sendrecv”, “a=service:duplex” and “a=sid:ID0 ID1 ID2 .. IDn” containing all established OVR call members (identifier from call participants of the outgoing OVR call unique over space and time) listed as call participants source ID separated by a single SPACE character, forming the OVR chain (if one exists). “IA-Tx: active, IA-Rx: active” MAY be indicated on the appropriate IA key on the IA panel of the ‘B’-party’s operator position.

3. Should the arrival of the OVR call cause the OVR call limit configured at the ‘B’-party to be exceeded, the ‘B’-party SHALL allow only a 2-party call to be established. In this case the ‘B’-party UA SHALL immediately send a 100 Trying followed by 200 OK response containing the “a=sendrecv”, “a=service:limited” and “a=sid:ID0 ID1 ID2 .. IDn” containing all established OVR call members.

Once the OVR call is established, a) the ‘B’-party SHALL send the Sum of ‘B’-party’s G/G plus A/G audio plus the

‘B’-party microphone audio (B∑G/G + A/G + B mic) on the monitoring path to the ‘A’-party and also on the monitoring path to the calling parties of any other of its established incoming OVR calls (if they exist). If the ‘B’-party also has its own outgoing OVR call connected to a ‘C’-party, it SHALL also add the G/G +A/G audio plus the ‘C’-party microphone audio received from the ‘C’-party to the audio sum being sent on the monitoring path towards the ‘A’-party and also on the monitoring path to the calling parties of any other of its established incoming OVR calls (if they exist).

b) the ‘B’-party SHALL also sum the received ‘A’-party G/G audio plus the ‘A’-party microphone (A∑G/G +A mic) with its own G/G audio plus the ‘B’-party microphone (B∑G/G +B mic) and also add the G/G audio plus microphone audio from the calling parties of any of its incoming OVR calls. This combined audio stream SHALL be sent on the forward path of its established outgoing OVR call towards the ‘C’- party.

c) the ‘B’-party SHALL issue a SIP INFO message (text/plain) containing its updated tail (including all tails terminating at ‘B’-party) to its established outgoing OVR call with the ‘C’-party (if one exists), in order to provide the ‘C’-party with updated information about its current audio connections (see 4.4.7). The summed audio stream being sent on the forward path to the ‘C’-party should reflect connections present in the tail terminating at ‘B’-party.

d) should the ‘B’-party receive a SIP INFO message (text/plain) defining an update to the local chain of its ‘C’-party, it SHALL issue a SIP INFO message (text/plain) containing its own updated chain to each established incoming OVR call (if any exist) in order to provide calling parties updated information about its current audio connections (see 4.4.6). The summed audio stream being sent on the monitoring path to each calling party should reflect connections present in the chain originating from ‘B’-party.

e) should the ‘B’-party receive a SIP INFO message (text/plain) defining an update to the local tail of its calling parties, it SHALL issue a SIP INFO message (text/plain) containing its own updated tail (including all tails terminating at ‘B’-party) to the established outgoing OVR call in order to provide the ‘C’-party updated information about its current audio connections (see 4.4.7). The summed audio stream being sent to the ‘C’ party should reflect connections present in the tail terminating at ‘B’-party.

f) on receipt of a BYE request from the ‘A’-party, the ‘B’-party UA SHALL send 200OK final response and clear the OVR call.

g) if the OVR call is cleared from the ‘B’-party, it SHALL send a BYE request to the ‘A’-party, the ‘A’-party UA SHALL respond with a 200OK final response and clear the OVR call.

© EUROCAE, 2012

29

If a two-party call is established because the ‘B’ party OVR call limit has been exceeded, a) the ‘B’-party SHALL send only the ‘B’-party microphone audio (B mic) to the ‘A’-

party, but SHALL continue to send A/G and G/G audio on the monitoring path to the calling parties of any other of its previously established incoming OVR calls (if they exist)

b) the ‘B’-party SHALL sum G/G audio plus microphone audio from the calling parties of any of its incoming OVR calls. This combined audio stream SHALL be sent on the forward path of its established outgoing OVR call towards the ‘C’- party (should one exist).

Once the OVR call has been cleared by either the ‘A’-party or the ‘B’-party, a) the ‘B’-party SHALL issue a SIP INFO message (text/plain) containing its

updated tail to its established outgoing OVR call with the ‘C’-party (if one exists), in order to provide the ‘C’-party with updated information about its current audio connections (see 4.4.6). The summed audio stream being sent on the forward path to the called party should reflect connections present in the tail terminating at the ‘B’-party.

4.4.5 OVR Call Parameter Values (Timers)

Timer T0 SHALL operate at the ‘A’-party UA during state IA-Awaiting-Confirmation. It SHALL be started on sending INVITE (Priority=“urgent”, Subject=“IA call”) and stopped on receipt 200 OK or 4xx-6xx final responses. Timer T0 SHALL have a value of 2 seconds. NOTE 13. The timer T0 may be set to other values according to ANSP specific

requirements.

4.4.6 OVR Call Loop Closure Detection method

Any time, a chain or tail is updated (via INVITE or INFO) a ‘B’-party shall compare the updated chain with the locally stored tail(s) or vice versa depending on which list had been received. In the case that there exists an intersection, meaning that there is at least one identifier which is element of the chain and a tail, when comparing the chain with any tail terminating at ‘B’-party, a loop closure has been detected. NOTE 14. In the case a loop has been detected via INFO only a party that acted as

‘B’ party in the last OVR call shall perform the following actions. In the case the ‘B’-party has detected a possible audio loop, a) the ‘B’-party SHALL NOT reject the INVITE request. The ‘B’-party SHALL

respond with a 100 Trying followed by a 200 OK response that contains an empty SDP “a=sid” attribute. Both the calling party and ‘B’-party are then aware of a loop in the audio chain, but only B-party shall take action in order to prevent this from occurring.

b) the ‘B’-party SHALL change its state to ‘OVR-loop’ and maintain a local intersection list containing all identifiers that are part of the updated tail and the chain.

c) the ‘B’-party SHALL NOT issue a SIP INFO message (text/plain) containing its own updated tail to the established outgoing OVR call.

d) the ‘B’-party SHALL NOT issue a SIP INFO message (text/plain) containing its own updated chain to the established incoming OVR call when a loop has been detected.

In the case that the ‘B’-party has detected a loop in the audio chain, in order to avoid acoustic feedback caused by a closed audio loop, it SHALL perform the following actions: • block all audio being received from the calling party (that caused the loop) • send only the ‘B’-party local Air-ground audio towards the calling party (i.e.

B∑A/G) The sent and/or received audio from all other incoming OVR calls to the ‘B’-party that hasn’t caused a loop is not affected.

© EUROCAE, 2012

30

4.4.7 OVR Call Loop Closure Rejection method

Any time, a chain or tail is updated a ‘B’-party set to ‘OVR-loop’ state shall compare the updated chain with the locally stored tail(s) or vice versa depending on which list had been received via INFO. In the case that there exists an updated intersection list and the set of elements comprising the new intersection (tail compared with chain) is less than the set of elements comprising the intersection when detecting the loop (implying that the intersection is unequal to the previously derived intersection), then loop closure has been rejected. In the case the ‘B’-party has detected loop closure rejection, a) the ‘B’-party SHALL change to normal operation as described in 4.4.4.3.

4.4.8 OVR Call A/G monitoring method

The following OVR call A/G monitoring method (reduced A/G monitoring channel) SHALL be followed: a) Each called ‘B’-party has information about all A/G channels in the OVR chain

and SHALL add only A/G communications which are not in the A/G monitoring channel.

b) The called ‘B’-party SHALL attenuate all A/G channels with a pre-configured value and send them together with the G/G channel to the calling ‘A’-party.

c) In order to distribute the frequency information, the called ‘B’-party SHALL add an SDP attribute “a=rid” in the 200 OK response that lists all radio IDs that are currently included in the A/G monitoring channel. The elements of the list “a=rid:RID1 RID2 .. RIDn” SHALL be unique over space and time and listed as radio IDs (RIDx) separated by a single SPACE character.

d) In the case the local radio ID list needs to be updated (due to a new frequency being added or a previous frequency being removed), an SIP INFO message (text/plain) containing the updated radio ID list SHALL be sent to each established incoming OVR call.

e) On receiving a 200 OK or a INFO message containing the list of radio IDs (associated with frequencies) currently contained in the OVR A/G monitoring channel, a party SHALL add-in only new local A/G radio IDs (associated with frequencies) that are not defined in the radio ID list, before sending the updated list to each of its established incoming OVR calls. A User Agent SHALL add audio from any of the local radio IDs (associated with frequencies) that are missing from the radio ID list to the audio in the OVR A/G monitoring channel.

NOTE 15. It is foreseen that the above defined method has the advantage that the interphone OVR A/G monitoring channel uses only one RTP stream (with one audio channel) and therefore the required bandwidth is the same as for a normal DA/IDA interphone call. It also has the advantage because audio from each A/G frequency is only included once in an OVR A/G monitoring channel. Even in the case that audio from the same A/G frequency is also locally available, the attenuated A/G monitoring channel will have only reduced influence on the audio quality.


4.4.9.1 Interaction with the Call Priority Interruption Supplementary Service

An OVR call SHALL NOT be pre-empted.

4.4.9.2 Interaction with the Call Hold Supplementary Service

Call hold SHALL NOT be invoked for an OVR call.

4.4.9.3 Interaction with the Call Transfer Supplementary Service

Call transfer SHALL NOT be invoked for an OVR call.

© EUROCAE, 2012

31

4.4.9.4 Interaction with the Call Intrusion Supplementary Service

Intrusion SHALL NOT be invoked for an OVR call; this means that the Priority header field included in an INVITE for an OVR call SHALL always take value “urgent” and never “emergency”. An OVR call SHALL NOT be intruded by a DA/IDA Priority call.

4.4.10 OVR Call Message Sequence Charts

The Message Sequence Charts (MSC) in figures below show the information flows between the ‘A’-party UA and the ‘B’-party UA. Each information flow is named according to the corresponding message sent to or received from respective party. Dashed lines (---) represent SIP signalling messages that are mandatory to the call scenario. The arrow indicates the direction of message flow. Double dashed lines (===) represent media paths between network elements.

FIGURE 9: OVR CALL FROM A-PARTY TO B-PARTY, OVR CALL ESTABLISHED AND A-PARTY CLEARS CALL

© EUROCAE, 2012

32

FIGURE 10: OVR CALL FROM A-PARTY TO B-PARTY,

OVR CALL ESTABLISHED AND B-PARTY CLEARS CALL

FIGURE 11: OVR CALL FROM A-PARTY TO B-PARTY,

B-PARTY THEN ESTABLISHES OUTGOING OVR CALL TO C-PARTY

© EUROCAE, 2012

33

FIGURE 12: OVR CALL FROM A-PARTY TO B-PARTY, OVR CALL IS REJECTED

FIGURE 13: OVR CALL FROM A-PARTY TO B-PARTY THAT EXCEEDS B’S MAX OVR CALL LIMIT, RESULTS IN A 2-PARTY CALL FOR CALL DURATION

© EUROCAE, 2012

34

FIGURE 14: OVR CALL FROM A TO B WHILE B HAS OUTGOING OVR CALL ESTABLISHED WITH C, AND C WITH D. OVR CALL FROM D TO A WILL CAUSE LOOP IN AUDIO CHAIN

FIGURE 15: OVR CALL FROM A PARTY TO B PARTY WHILE B HAS RADIO SESSIONS WITH F1 AND F2

© EUROCAE, 2012

35

4.5 CALL HOLD

The Hold service allows a user to disconnect temporarily from an established call in order to carry out other telephony functions before returning to the original established call. Call Hold SHALL be handled as indicated in section 2.1 (“Call Hold”) and section 2.2 (“Consultation Hold”) of RFC 5359 Session Initiation Protocol Service Examples [29].

4.6 CALL TRANSFER

The Call Transfer service enables a user involved in an active call to establish a new call between the other user in the active call and a third party. Call Transfer SHALL be handled as indicated in section 2.4 (“Transfer – Unattended”) and section 2.5 (“Transfer - Attended”) of RFC 5359 Session Initiation Protocol Service Examples [29], where it is stated that the call can only be transferred within the existing dialog.

4.7 “MEET ME” CONFERENCE

The Conference service enables a user to interconnect a number of parties allowing full speech facilities to all connected parties. To create a “Meet Me” conference, users SHALL call at an agreed time, a pre-determined conference number. A “Meet Me” conference SHALL be created according to section 5.1 of RFC 4579 (“INVITE: Joining a conference using the conference URI – dial-in”) [28].

4.8 BROADCAST CONFERENCE

The conference initiator may sequentially call users to establish the conference or add new participants. In this case, all users in an established conference SHALL hear a notification tone when a new participant joins the conference. In addition, at the request of the conference initiator, users belonging to a pre-defined list are automatically called and placed in conference (preset conference), allowing full speech facilities to all connected parties.

4.8.1 Operational Requirements

1. The Conference Entry Notification Tone feature SHALL be configurable (enable/disable).

2. All conferees SHALL hear a Conference Entry Notification Tone when a new participant joins the conference and the Conference Entry Notification Tone feature is active.

3. The initiator of a conference SHALL be able to eliminate participants selectively from the conference at any time (drop from conference) as long as the initiator is part of that conference.

4. Any user (including the initiator) MAY leave the conference at any stage. 5. The particular characteristic of the Conference in case the initiator leaves the

conference SHALL be configurable. Either the conference bridging resource (focus) allows the remaining users to stay interconnected (conference_stays_when_initiator_leaves), or the conference ends up and the bridging resource gets released (conference_ends_when_initiator_leaves).

4.8.2 Interoperability General Requirements

1. A Broadcast conference MAY be created according to section 5.4. of RFC 4579 (INVITE: Creating a conference using the ad-hoc SIP methods) [28].

2. The initiator of a conference SHALL: a. either provide a focus role (‘isfocus’) if it hosts the conference and

maintains SIP signalling relationship with each participant;

© EUROCAE, 2012

36

NOTE 16. Note that this method does not deny the capability of leaving the conference by either ending the conference (conference_ends_when_initiator_leaves), or letting the conference 'alive' (conference_stays_when_initiator_leaves). In that case, the capability of establishing a new conference depends on internal (VCS, Position) capabilities.

b. either invite a supporting conference URI (focus), possibly selected through a Conference factory, that will host the conference and maintain SIP signalling relationship with each participant.

NOTE 17. Note that all possible conference IDs must be known in advance. 3. The focus (‘isfocus’) is responsible for the conference state distribution and

SHOULD support the RFC 4575 “Event Package for Conference State” [27]. 4. Each conference aware participant (supporting isfocus) SHOULD subscribe to

the conference URI (SUBSCRIBE/NOTIFY) [10]. 5. A conference device that occupies the focus role SHALL continue hosting the

conference even if the conference degrades to a two party communication. 6. On receipt of a notification (NOTIFY request) of a new participant joining the

conference, each conferee UA MAY display the participants name on a user interface.

7. A conference device that occupies the focus role SHALL generate the “Conference Entry Notification” audible tone if a new participant is joining the conference, whenever this tone feature is enabled by configuration.

4.8.3 Execution of a Conference

This section focuses on the initial move from a simple two-party connection to a conference and in addition the adding of further parties. Conference creation is based on SIP ad-hoc methods according to RFC 4579 [28]. NOTE 18. Please note that conference factory and focus are logical roles. The execution of a conference SHALL be based on RFC 3891 (“Replaces Header”) [22], RFC 3515 (“Refer Method”) [14], RFC 4575 (“Event Package for Conference State”) [27] and RFC 4579 (“Call Control - Conferencing for User Agents”) [28].

4.8.3.1 Conference Factory

The conference factory is a possible solution to maintain conference URIs dynamically. The Conference factory is not required if the conference URI is known at the SIP UA (for example by parameterization) or if the SIP UA itself has the capability to behave as a focus.

SIP UAA

ConferenceFactory

Conf1(Focus)

SIP UAB

INVITE sip:Conference Factory

302 Moved Contact:Conf1;isfoucs

Conference URI (focus) resource request

Media Session

ACK

FIGURE 16: CONFERENCE URI (FOCUS) RESOURCE REQUEST

© EUROCAE, 2012

37

4.8.3.2 Migration to conference

FIGURE 17: SESSION BETWEEN UA A AND B, CF NOT INVOLVED

Media Session

SIP UAA

Conf1(Focus)

SIP UAB

200 OK

NOTIFY

200 OK

SUBSCRIBE sip:Conf1

Invitation of conference URI (focus)

Media Session

INVITE sip:Conf1

180 Ringing

200 OK Contact:Conf1;isfocus

ACK

subscription is optional

FIGURE 18: MESSAGE FLOW, UA A REQUESTS FOCUS

© EUROCAE, 2012

38

Media Session

SIP UAA

SIP UAB (Focus)

200 OK

NOTIFY

200 OK

SUBSCRIBE sip:Conf1

Invitation of conference URI (focus)

Media Session

reINVITE sip:B

180 Ringing

200 OK Contact: sip:B;isfocus

ACK


FIGURE 19: SESSION BETWEEN UA A AND UA B, B IS CONFERENCE FOCUS (CF)

Media Session

SIP UAA (Focus)

SIP UAB

200 OK

NOTIFY

200 OK

SUBSCRIBE sip:A

Invitation of conference URI (focus=initiator)

Media Session

reINVITE sip:B; Contact: sip:A; isfocus

200 OK

ACK


FIGURE 20: MESSAGE FLOW, FOCUS HOSTED BY UA A

© EUROCAE, 2012

39

FIGURE 21: UA A HAS REQUESTED FOCUS

Media Session

SIP UAA

Conf1(Focus)

SIP UAB

Replacement of partner connection

Media Session

REFER sip:Conf1 Refer-To:B?Replaces=A-B

202 Accepted

NOTIFY (Trying)

200 OK

INVITE sip:Conf1;isfocus Replaces:A-B

200 OK

ACK

Media Session

BYE

200 OK

NOTIFY (200)

200 OK

Media Session Terminated

SUBSCRIBE sip:Conf1

Note: partner NOTIFY processing between focus and participants out of drawing scope.

200 OK


FIGURE 22: MESSAGE FLOW, UA A REQUESTS FOCUS TO INVITE B

© EUROCAE, 2012

40

FIGURE 23: UA A AND B HAVE CONFERENCE AT FOCUS

4.8.3.3 Adding participants

Media Session

SIP UAA

SIP UAC

SIP UAB

Inviting new partner

REFER sip:Conf1 Refer-To:C

202 Accepted

NOTIFY (Trying)

200 OK

INVITE sip:Conf1;isfocus

180 Ringing

Media Session

SUBSCRIBE

NOTIFY (200)

200 OK

200 OK

200 OK

ACK

Note: partner NOTIFY processing between focus and participants out of drawing scope


Conf1(Focus)

FIGURE 24: MESSAGE FLOW, UA A REQUESTS FOCUS TO INVITE C

© EUROCAE, 2012

41

FIGURE 25: THREE PARTY CONFERENCE WITH FOCUS

NOTE 19. To invite another partner (other SIP session, e.g. A-E) Figure 22 “Replace partner connection” applies.

If the focus role is played by a participant of the conference, e.g. SIP UA X, the same method applies with SIP UA X instead of Focus (Conf1).

4.9 INTRUSION

The Call Intrusion service is related to Priority DA/IDA call handling, as it is the effect of a Priority call at a Busy Called UA. In the event that the Calling user has made a Priority call but encounters the Called user busy, Intrusion SHOULD take place automatically. If permitted, upon Intrusion all parties SHALL be connected together in conference. Before the intrusion occurs a visual and/or audible intrusion notification SHALL be given to users. It SHOULD be possible for any user to be protected against intrusion by other users. This protection SHALL be selectable individually on a user-by-user basis. In the case that intrusion is not permitted, the call SHALL still be presented at the CWP. An unwanted user of a call intrusion (the user other than the wanted user in the established call that is to be intruded) with call protection SHALL be unable to prevent a call intrusion.

4.9.1 Interoperability General Requirements

For the Call Intrusion service the following requirements SHALL be fulfilled: 1. Every SIP end SHOULD act as focus (IETF RFC 3840 [19]) for a conference

and its URI SHOULD be a conference URI, therefore: • Once a Priority call is connected, the calling party (SIP End User Agent or

Gateway) MAY send a SUBSCRIBE message (IETF RFC 3265 [10]) to request notification from Called User about the users in the “conference session”.

2. Call Intrusion Protection Level (CIPL) of the Unwanted User (the user other than the wanted user in the established call that is to be intruded) SHALL be assumed as off, that is, Call Intrusion is allowed. Call intrusion SHALL happen unless it is not allowed by the Wanted User or the established active call is a Priority call (Priority header field = “emergency”).

3. Dialogue Package (IETF RFC 4235 [24]): • All SIP user agents SHOULD be able to use a dialogue package allowing

them to transmit notification of a change in their state to nominated subscribers;

• The Allow-Events header field in a SUBSCRIBE method SHALL indicate “dialog”, the Event header field SHALL indicate “dialog”, and the Expires header field SHOULD be “3600” (1 hour);

• Dialogue info sent by the User Agent SHOULD define: state = “partial”, entity = user URI;

• Dialogue id SHOULD also include optional attributes: call-id, local-tag, remote-tag, for each change in state;

© EUROCAE, 2012

42

• Possible States include: “Trying”, “Proceeding”, “Early”, “Confirmed” and “Terminated”;

• For a call intrusion to occur, the callee SHALL be in a “Confirmed” state (Active). The “Confirmed” state and the “Terminated” state only SHOULD therefore be indicated in dialogue sent by a SIP User Agent; “Terminated” implies no active call in progress; “Confirmed” implies an active call in progress.

4. Use SHALL be made of the INFO method (RFC 2976 [7]) (Content-Type: text/plain) to inform users and gateways of status of the intrusion (“Intrusion in progress”, “Intrusion completed”): a) Visual and/or audible intrusion notifications SHALL be indicated to

Unwanted party/parties upon receipt of an INFO request (RFC2976 [7]) containing a message body (Content-Type: text/plain) with the following content: “Intrusion in progress”, “Intrusion completed”, or “Intrusion cancelled” within a SIP dialog.

b) Visual and/or audible notifications SHALL be indicated to Calling (Served) user via the provisional responses 182 (Queued) and 183 (Intrusion in progress), as according to RFC3261 (7.2 Responses) [8], implementations MAY choose other text for the Reason-Phrase.

4.9.2 Execution of Priority Call Intrusion

When Priority call is invoked by the Calling (Served) user, the Calling UA SHALL send an INVITE request with a Priority header field defined as “emergency” to distinguish it from routine DA/IDA call (with Priority header field defined as “urgent”, “normal” or “non-urgent”). If Intrusion is allowed (e.g. CIPL off) by the Wanted user (i.e. the called user in the intruding call) and the Wanted user is busy, the Wanted UA SHALL reply with a 182 (Queued) response and start timer T1 (0 ≤ T1 ≤ ANSP dependent value). NOTE 20. The Intrusion warning period ‘T1’ should be configurable. If the Wanted user releases resources before T1 elapses, the Wanted UA SHALL send a 200 (OK) final response to the INVITE (emergency) either automatically or once the Priority Call is manually answered (ANSP dependent). Should T1 elapse, the Wanted UA SHALL send a reINVITE request to the Unwanted UA(s) (UA other than the Wanted UA in the established call that is to be intruded) and a 183 (“Intrusion in progress”) provisional response to the Calling UA. In case of T1 = 0 (as configured by a specific ANSP), on receiving the INVITE (emergency) request, the Wanted UA SHALL NOT send the 182 (Queued) provisional response and proceed directly as specified in the former paragraph. On receiving the reINVITE request, the Unwanted UA SHALL send a 200 (OK) final response to the previous reINVITE. Upon receipt of the 200 (OK) response, the Wanted UA SHALL send the corresponding ACK and an INFO request containing a Text/Plain body indicating “Intrusion in progress” to the Unwanted UA. Besides, the Wanted UA SHALL send a 200 (OK) final response to the Calling UA, to allow the Calling user to enter the conference media session. The Wanted UA SHALL then act as the focus for the conference (use SHALL be made of the “isfocus” feature, defined in IETF RFC 3840 [19], to create a conference media session). Once the intrusion is effective, Served and Unwanted UAs MAY send a dialog subscription (SUBSCRIBE request) to the Wanted UA; then it SHALL reply with a notification (NOTIFY request) defining all parties in the conference media session. If the Unwanted User leaves the conference, the Wanted UA SHALL send an INFO request containing a Text/Plain body indicating “Intrusion completed” and a reINVITE request (it’s not focus anymore) to the Served UA. If the Served user leaves the conference, the Wanted UA SHALL send a reINVITE request (it’s not focus anymore) to the Unwanted UA.

© EUROCAE, 2012

43

If intrusion is forbidden by the Wanted UA (e.g. CIPL on, or Wanted UA has already a Priority Call)), the Wanted UA user SHALL reply with a 180 (Ringing) response; Wanted and Unwanted users remain connected. The call is displayed at the user’s terminal as a Priority Call and can be manually answered. A 182 (Queued) response SHALL NOT be sent by the Wanted UA.

4.9.3 Message Sequence Charts

The figures below show some typical message sequences that can occur for the intrusion interworking between SIP ends. Each information flow in a Message Sequence Chart (MSC) is named according to the corresponding message sent to or received from a peer UA. Dashed lines (---) represent signalling messages that are mandatory to the call scenario. The arrow indicates the direction of message flow. Double dashed lines (===) represent media paths between network elements.

SIP UA A(Served User)

SIP UA C(Unwanted User)

SIP UA B(Wanted User)

INVITE(emergency)

Priority call answered before a predefined time interval

Media Session

BYE

200 OK

200 OK

Media Session

T < T1

ACK

182 QueuedVisual and/or audible intrusion notification to Wanted User

Automatically or manually answered

Visual and/or audible notification to Served User

FIGURE 26: PRIORITY CALL ANSWERED AFTER RELEASING RESOURCES

© EUROCAE, 2012

44

INVITE(emergency)

Successful Priority Call Intrusion (single session)

reINVITE Contact B; isfocus (intrusion)

200 OK

200 OK Contact B; isfocus

183 Intrusion in progress

INFO “Intrusion in progress”

Visual and/or audible intrusion notification to Unwanted User

Media Session

200 OK

T1

ACK

ACK

182 Queued



SIP UA B (focus)(Wanted User)

Visual and/or audible intrusion notification to Wanted User

Media Session

Media Session

Visual and/or audible notification to Served User

Visual and/or audible intrusion notification to Served User

FIGURE 27: PRIORITY CALL INTRUSION TO A SINGLE CALL

INVITE(emergency)

Successful Priority Call Intrusion (conference)

Media Session


200 OK

200 OK Contact B;isfocus




Visual and/or audible intrusion notification to user

Note: There are two conferences at the same time, each one with its own focus. The first one is the former conference {B, C and Focus(isfocus)} and the second one is the conference resulting from the intrusion {A, B(isfocus) and Focus}.

200 OK

200 OK

T1

ACK

ACK

SIP UAA (Served)

SIP UAC

Conf1(Focus)

SIP UAB (Focus)

182 Queued

Visual and/or audible notification to user


FIGURE 28: INTRUSION TO CONFERENCE

NOTE 21. Please, note that there is no difference between single session and conference intrusion processes.

© EUROCAE, 2012

45

INVITE(emergency)

Automatic Priority Call Intrusion with T1 = 0


200 OK




Visual and/or audible intrusion notification to Unwanted User

Media Session

200 OK

ACK

ACK



SIP UA B (focus)(Wanted User)

Visual and/or audible intrusion notification to Wanted User

Media Session

Media Session

Visual and/or audible intrusion notification to Served User

FIGURE 29: AUTOMATIC PRIORITY CALL INTRUSION WITH T1 = 0

SIP_ End2 Ca ll in trusion Protect io n-ONSIp End2 does not act asfocu s for confe rence

INVITE (emergency) INVITE (emergency)100 Trying

180 Ringing180 Ringing

200 OK200 OK

ACKA CK

Call man ually an sweredby SIP_End2 user

Priority Call Intrusion Forbidden by Wanted UserPriority call is displayed at SIP_End2 and manually answered

Call displayed as Priority call at SIP_End2

Co nference Media Session: 2 p arties

Priority Header =n ormal

Media Sessio n: 2 parties

SIP_E nd1(Served User)

SIP_End2(Wanted User)

SIP_End3(Unwanted User)

Proxy

FIGURE 30: PRIORITY CALL INTRUSION FORBIDDEN BY WANTED USER

© EUROCAE, 2012

46



200 OK200 OK

ACKACK

Call manually answeredby SIP_End1 user

Priority Call Intrusion into another Priority Call ForbiddenPriority call is displayed at SIP_End2 and manually answered

Call indicated as Priority call at SIP_End2

Media Session: 2 parties

Priority Header =emergencyl


SIP_End1(Served User)

SIP_End2(Wanted User)

SIP_End3(Unwanted User)

Proxy

FIGURE 31: PRIORITY CALL INTRUSION INTO ANOTHER PRIORITY CALL FORBIDDEN

SIP UAA (Served)

SIP UAC

SIP UAB (Focus)

BYE

200 OK

Call Clearing by Intruder Party

Media Session

reINVITE Contact B (is not focus anymore)

200 OK

Media Session terminated ACK

Media Session

FIGURE 32: CALL CLEARING BY INTRUDER PARTY

© EUROCAE, 2012

47

SIP UAA (Served)

SIP UAC

SIP UAB (Focus)

BYE

200 OK

Call Clearing by Intruded Party

Media Session

200 OK

BYE

Media Sessions terminated

FIGURE 33: CALL CLEARING BY INTRUDED PARTY

SIP UAA (Served)

SIP UAC (Unwanted)

SIP UAB (Focus)

Call Clearing by other Party

Media Session


200 OK

Media Session terminated

BYE

200 OKINFO “Intrusion completed”

200 OK

ACK

FIGURE 34: CALL CLEARING BY OTHER (‘UNWANTED’) PARTY

© EUROCAE, 2012

48

SIP UAA (Served)

SIP UAC

Conf1(Focus)

SIP UAB (Focus)

Call clearing request by a conference focus

Media Session

BYE

200 OK


200 OK

Media Session terminated

INFO “Intrusion completed”

200 OK

ACK

FIGURE 35: CALL CLEARING REQUEST BY A CONFERENCE FOCUS

4.10 POSITION MONITORING

The Position Monitoring service enables a user to hear any active voice call at other user position; the served (monitoring) user hears audio transmitted and received by the monitored position. NOTE 22. This service has to be understood as an independent facility that has

nothing to do with the audio monitoring channel present in Instantaneous Access calls.

Position monitoring SHOULD be based on the following principle: The monitoring feature SHALL be configurable (enabled/disabled) and to establish the monitoring session, the monitoring position SHALL send an INVITE containing the Subject header content “monitoring” (Subject=”monitoring”). If monitoring is disabled at the target position, the monitored position SHALL send a SIP 488 (Not Acceptable Here) response. If monitoring is enabled, the calling party MAY hear a combination of: • transmitted and/or received audio from any active DA/IDA telephone voice calls

at the called party’s CWP; and/or • transmitted and/or received audio from any other active IA calls at the called

party’s CWP; and/or • transmitted and/or received audio from any active radio voice calls at the called

party’s CWP; and/or • any other audio signal suitably injected in the audio path to the calling user, but

excluding audio signals received from a monitored party’s CWP. Such audio combination SHALL be configurable according to ANSP specific requirements, for the whole system or for specific user terminals. To limit combinations to A/G or G/G audio sources, the monitoring position SHALL send an INVITE containing the Subject header content “A/G monitoring” (Subject=”A/G monitoring”) or “G/G monitoring” (Subject=”G/G monitoring”), respectively. Position monitoring indication SHALL be configurable according to ANSP specific requirements. If position monitoring indication is enabled, it SHOULD be indicated at the position being monitored. If position monitoring indication is not enabled, it SHALL not be indicated. To terminate a Position Monitoring session, the monitoring position SHALL send a BYE request to the monitored position.

© EUROCAE, 2012

49

4.11 PRESENCE INFORMATION Presence information MAY be thought of as the state of a user or device at a particular instant. Within the ATS environment, presence information MAY be used to indicate if a particular remote CWP is operational or not. NOTE 23. Today an ATC supervisor or technical staff may only be informed of a

communication problem when either automatic period test calls have failed or a controller can no longer make calls to a remote CWP.

Using Presence information, any user working within an ATS unit MAY be informed in real time of the operational status of every CWP in their neighbouring ATS units. If a particular CWP was closed down, a message informing them of the fact MAY be sent. It would involve the user agent or server (called “watcher”) making a subscription (long term relationship) with the Presence Agent located within all neighbouring ATS units. NOTE 24. The Presence Agent is an application running on a Server (i.e. Presence

Server or Proxy Server), capable of identifying the presence status of all the registered CWPs in that domain.

This subscription MAY request presence information changes to the relevant CWPs in that ATS unit. Once a subscription was made, every time a CWP was closed or opened, notification MAY be sent to the subscriber (“watcher”). This MAY lead to improved safety as an ATS unit MAY know the present status of the CWPs in all its neighbouring ATS units. Presence information SHALL be handled as defined by the Presence Event Package for the Session Initiation Protocol (SIP) (RFC 3856, [20]).

4.12 DETECTION OF LINK CONNECTION LOSS The system SHALL check if telephone call setups are possible to all ATSU locations that have been configured using the OPTIONS method (RFC 3261, [8]) to ping the corresponding VCS servers or gateways.

4.13 AUDIBLE TONES

A SIP UA SHALL be capable of generating the tones indicated in Table 9. NOTE 25. Tone generation should however be configurable for the whole system or

for specific user terminals, since some ANSPs would prefer to display messages instead of presenting audio tones to the user.

In the case where interworking with legacy systems is required, tones generated at the legacy side SHALL be transparently forwarded to the SIP end over the IP network as inband tone. Tones generated at the gateway SHALL be injected into the voice path towards the legacy end and SHALL be announced via SIP INFO over the IP network towards the SIP end. Any INFO messages received from the SIP end SHALL result in audible tones being injected into the voice path towards the analogue end.

Audible Tone Locally generated

Sent over the IP

Network Purpose Tone generated upon

receipt of:

Ringing Yes No To indicate successful call establishment and prior to call acceptance by the called user.

• 180 (Ringing) • 182 (Queued) • 183 (Session progress)

Hold Yes No To indicate that a call has been placed on hold, refer to [29].

• SDP: a=sendonly • SDP: a=inactive

Terminal busy Yes No To indicate that all available voice paths to a called user are occupied.

• 480 Temporarily Unavailable • 486 Busy Here • 600 Busy Everywhere • 603 Decline

Congestion Yes No To indicate that a call cannot be completed to a called user due to appropriate inter-VCS links being occupied or otherwise unavailable.

• 503 Service Unavailable

© EUROCAE, 2012

50

Audible Tone Sent over Locally Tone generated upon

generated the IP Purpose receipt of: Network

Number Unobtainable Yes No

To indicate that a terminal is "out of service" or the called user address is unassigned.

• 400 Bad Request • 401 Unauthorized • 403 Forbidden • 404 Not Found • 405 Method Not Allowed • 406 Not Acceptable • 407 Proxy Authentication

Required • 408 Request Timeout • 410 Gone • 413 Request Entity Too

Large • 414 Request URI Too Long • 415 Unsupported Media Type• 416 Unsupported URI

Scheme • 420 Bad Extension • 421 Extension Required • 423 Interval Too Brief • 481 Call Leg/Transaction

Does Not Exist • 482 Loop Detected • 483 Too Many Hops • 484 Address Incomplete • 485 Ambiguous • 488 Not Acceptable Here • 489 Bad Event • 491 Request Pending • 493 Undecipherable • 500 Server Internal Error • 501 Not Implemented • 502 Bad Gateway • 504 Server Time-out • 505 Version Not Supported • 513 Message Too Large • 604 Does Not Exist

Anywhere • 606 Not Acceptable

Conference notification No Yes To indicate that a new participant is

joining the conference.

• N. A. (as it is generated by the conference device that occupies the focus role)

Intrusion warning Yes No

Locally injected into the voice paths of both Wanted and Unwanted user CWPs of a call intrusion, to warn of the imminent priority conferencing of their established routine call.

• INVITE request with SIP Priority header field “emergency” received at SIP End to a Wanted User CWP that results Busy with a routine call-in-progress (only in case intrusion is permitted)

• INFO (“Intrusion in progress”) request received at SIP End of the Unwanted User CWP of a call intrusion.

Interrupt warning Yes No

Locally injected into the voice path of a user CWP to warn of the imminent interruption of its established routine call with a user in the legacy side of the network.

• INFO (“Interruption is impending”) request received at the SIP End of the User CWP selected for interruption of its established routine call with user in legacy network because an INVITE request with SIP Priority header field “emergency” received at Gateway found congestion on the legacy side of the network.

© EUROCAE, 2012

51

Audible Tone Sent over Locally Tone generated upon

generated the IP Purpose receipt of: Network

Yes Yes

Remotely injected into the voice path of a user CWP to warn of the imminent interruption of its established routine call with a user in the legacy side of the network.

• A Priority call request from the Legacy end that finds congestion on the legacy side of the network towards a Gateway selects an established routine call with a user at SIP end for interruption. In this case an inband tone is generated by the Legacy End towards the SIP End and sent over the IP network.

TABLE 9 – AUDIBLE TONES GENERATED BY SIP ENDS

© EUROCAE, 2012

52

ANNEX A

REFERENCES

[1] RFC 768: “User Datagram Protocol”, August 1980. [2] RFC 791: “Internet Protocol”, September 1981. [3] RFC 793: “Transmission Control Protocol”, September 1981. [4] RFC 2046: “Multipurpose Internet Mail Extensions (MIME) Part Two: Media

Types", November 1996. [5] RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels", BCP

14, March 1997. [6] RFC 2460: “Internet Protocol, Version 6 (IPv6) Specification”, December 1998 [7] RFC 2976: “The SIP INFO Method”, October 2000. [8] RFC 3261: “SIP: Session Initiation Protocol”, June 2002. [9] RFC 3264: “An Offer/Answer Model with the Session Description Protocol

(SDP)”, June 2002. [10] RFC 3265: “Session Initiation Protocol (SIP)-Specific Event Notification”, June

2002. [11] RFC 3326: “The Reason Header Field for the Session Initiation Protocol (SIP)”,

December 2002. [12] RFC 3398: “Integrated Services Digital Network (ISDN) User Part (ISUP) to

Session Initiation Protocol (SIP) Mapping”, December 2002. [13] RFC 3428: “Session Initiation Protocol (SIP) Extension for Instant Messaging”,

December 2002. [14] RFC 3515: “The Session Initiation Protocol (SIP) Refer Method”, April 2003. [15] RFC 3550: “RTP: A Transport Protocol for Real-Time Applications”, July 2003. [16] RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples,

December 2003. [17] RFC 3666: “Session Initiation Protocol (SIP). Public Switched Telephone

Network (PSTN) Call Flows”, December 2003. [18] RFC 3676: "The Text/Plain Format and DelSp Parameters", February 2004. [19] RFC 3840: “Indicating User Agent Capabilities in the Session Initiation Protocol

(SIP)”, August 2004. [20] RFC 3856: “A Presence Event Package for the Session Initiation Protocol

(SIP)”, August 2004. [21] RFC 3863: “Presence Information Data Format (PIDF)”, August 2004. [22] RFC 3891: “The Session Initiation Protocol (SIP) ‘Replaces’ Header”,

September 2004. [23] RFC 3911: “The Session Initiation Protocol (SIP) ‘Join’ Header”, October 2004. [24] RFC 4235: “An INVITE-Initiated Dialog Event Package for the Session Initiation

Protocol (SIP)”, November 2005. [25] RFC 4346: “The Transport Layer Security (TLS) Protocol - Version 1.1”, April

2006. [26] RFC 4566: “SDP: Session Description Protocol”, July 2006. [27] RFC 4575: “A Session Initiation Protocol (SIP) Event Package for Conference

State”, August 2006. [28] RFC 4579: “Session Initiation Protocol (SIP) Call Control – Conferencing for

User Agents”, August 2006. [29] RFC 5359: “Session Initiation Protocol Service Examples”, October 2008. [30] Eurocontrol. “ATS R2 and ATS No.5 Signalling Protocol Specifications”, Ed. 1.0

(February 2005).

© EUROCAE, 2012

53

[31] ITU-T. Rec. G.711. “Pulse Code Modulation (PCM) of Voice Frequencies”, November 1988.

[32] ITU-T. Rec. G.728. “Coding of Speech at 16 Kbit/s Using Low-delay Code Excited Linear Prediction”, September 1992.

[33] ECMA-143: “Private Integrated Services Network (PISN); Circuit Mode Bearer Services; Inter-Exchange Signalling Procedures and Protocol (ISO/IEC 11572)”.

[34] ECMA-312: “Private Integrated Services Network (PISN); Profile Standard for the Use of PSS1 (QSIG) in Air Traffic Services Networks”.

[35] ECMA-339: “Corporate Telecommunication Networks; Signalling Interworking between QSIG and SIP; Basic Services”.

© EUROCAE, 2012

54

ANNEX B

ACRONYMS

Ack Acknowledge AGVN Air Traffic Services Ground Voice communications Network A/G Air/Ground AM Amplitude Modulation ANSP Air Navigation Service Provider ATA Analogue Telephone Adapter ATC Air Traffic Control ATM Air Traffic Management ATS Air Traffic Services AVP Audio/Video Profile CICL Call Intrusion Capability Level CIPL Call Intrusion Protection Level CPICL Call Priority Interruption Capability Level CPIPL Call Priority Interruption Protection Level CWP Controller Working Position DA Direct Access DNS Domain Name Service ECMA European Computer Manufacturers Association G/G Ground/Ground HMI Human Machine Interface HTTP HyperText Transfer Protocol IA Instantaneous Access IANA Internet Assigned Numbers Authority ICCVC Instantaneous Controller-Controller Voice Communication IDA InDirect Access IETF Internet Engineering Task Force IP Internet Protocol ISDN Integrated Services Digital Network ITU-T International Telecommunication Union – Telecommunication

standardization sector LAN Local Area Network LD-CELP Low Delay - Code Excited Linear Prediction MF Multi-Frequency MFC Multi-Frequency Code MSC Message Sequence Chart N. A. Not Applicable PABX Private Automatic Branch eXchange PCM Pulse Code Modulation PINX Private Integrated services Network eXchange PISN Private Integrated Services Network PSS1 Private Signalling System no. 1 PSTN Public Switched Telephone Network QoS Quality of Service Rec. Recommendation

© EUROCAE, 2012

55

RFC Request For Comments RTCP Real-time Control Protocol RTP Real-time Transport Protocol Rx Reception S/MIME Secure / Multipurpose Internet Mail Extensions SDP Session Description Protocol SIP Session Initiation Protocol SS-IA Instantaneous Access Supplementary Service TCP Transmission Control Protocol TDM Time Division Multiplexing TLS Transport Layer Secure protocol TU Transaction User Tx Transmission UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Universal Resource Identifier UHF Ultra-High Frequency VCS Voice Communications System VHF Very High Frequency VoIP Voice over the Internet Protocol WAN Wide Area Network

© EUROCAE, 2012

56

© EUROCAE, 2012

ANNEX C

LIST OF EUROCAE WG-67 CONTRIBUTORS


ADRIAN Andre DFS

BARABAN Luc CSSI

BICA Dumitru ROHDE & SCHWARZ TOPEX

GELADA Mario ATIS


MARTÍN Miguel A. AENA

PABLOS Sergio INDRA SISTEMAS

PALMER John S. JSP-TELECONSULTANCY

POTIRON Guy DSNA, EUROCAE WG-67 CHAIRMAN

SMITH Barry FAA


WEGER Roberto SITTI


82

6.6.3 Derivation of Attributes Type in SDP

The incoming gateway SHALL generate SDP information to include in the SIP INVITE request based on the Bearer Capability information element received in the ATS-QSIG SETUP message. The attribute type included in the SDP information SHALL be according to Table 20.

ATS-QSIG SDP Information Transfer Capability in Bearer

Capability information element Attributes of media session

"Speech" (00000) rtpmap:15 G728/8000

TABLE 20 – MEDIA ATTRIBUTES (“A=”) SETTING IN SDP BASED ON BEARER CAPABILITY INFORMATION ELEMENT

6.7 REQUIREMENTS FOR SUPPORT OF SUPPLEMENTARY SERVICES

A gateway SHALL support the Call Priority Interruption and the Call Intrusion supplementary services.

6.7.1 Call Priority

6.7.1.1 Mapping of ATS-QSIG Priority Levels to SIP Priority Header Field

On receipt of a call from the ATS-QSIG network, the Gateway SHALL initiate the call towards the IP network. The Gateway SHALL read the ATS-QSIG Facility information elements defining the CPICL, CPIPL and CICL of the call and include the relevant Priority header field in the SIP INVITE request with values as specified in Table 21.

Gateway Input ATS-QSIG CPICL, CPIPL and CICL

Gateway Output SIP Priority Header Field Call Type

CPICL = 3 CPIPL = 3 CICL = 3

emergency Priority call

CPICL = 0 CPIPL = 2 or 3

CICL = 0 urgent Tactical Routine call


normal Strategic Routine call


non-urgent General Purpose Routine call

TABLE 21 – MAPPING OF ATS-QSIG CPICL, CPIPL AND CICL TO SIP PRIORITY HEADER FIELD

In the case that Facility information elements defining the CPICL, CPIPL and CICL are not present, then it SHALL be assumed that their values are zero. In those exceptional cases when Facility information elements defining the CICL and/or CPICL with values of 1 or 2, then values of zero SHALL also be assumed.

© EUROCAE, 2012

83

6.7.1.2 Mapping of SIP Priority Header Field to ATS-QSIG Priority Levels

On receipt of a SIP INVITE request from the IP network, the Outgoing Gateway SHALL attempt to establish a call towards the ATS-QSIG network. The Outgoing Gateway SHALL also map the Priority header field of the SIP INVITE request to the equivalent ATS-QSIG priority levels as specified in Table 22.

Gateway Input SIP Priority Header Field

Gateway Output ATS-QSIG CPICL, CPIPL and CICL Call Type

emergency CPICL = 3 CPIPL = 3 CICL = 3

Priority call

urgent CPICL = 0 CPIPL = 2 CICL = 0

Tactical Routine call (Medium Interrupt Protection)

normal CPICL = 0 CPIPL = 1 CICL = 0

Strategic Routine call (Low Interrupt Protection)

non-urgent CPICL = 0 CPIPL = 0 CICL = 0

General Purpose Routine call(No Interrupt Protection)

TABLE 22 – MAPPING OF SIP PRIORITY HEADER FIELD TO ATS-QSIG PRIORITY LEVELS

In the case that Facility information elements defining the CPICL, CPIPL and CICL have the value zero, it is not mandatory to include them in the ATS-QSIG SETUP message. If the resulting Call Priority Interrupt Protection Level CPIPL of the calling party < 3 at the gateway output, the CPIPL negotiation SHALL take place only between endpoints in the ATS-QSIG network.

6.7.2 Priority Call Interruption

Every call (Priority or Non-priority) SHALL be associated with a CPIPL value, however: • A Priority call SHALL NOT be interrupted from any end. • A Routine call with CPIPL = 3 (highest protection) SHALL NOT be interrupted

from any end. • A Routine call with a CPIPL < 3 MAY be interrupted from the ATS-QSIG End or

by the gateway when congestion exists. • When a non-priority call was originated from the ATS-QSIG_End, the CPIPL of

the established call SHALL be associated with the CPIPL value in the ATS-QSIG SETUP message.

• When a non-priority call was originated from the SIP_End, the CPIPL of the established call SHALL be associated with the higher of the CPIPL values in the ATS-QSIG SETUP message and corresponding ATS-QSIG CONNECT message.

6.7.2.1 Priority Call Interruption from SIP to ATS-QSIG

On receipt of a SIP INVITE (emergency) request from the IP network and all B-channels in the preferred route of the circuit-switched network being occupied, the gateway SHALL attempt to establish a Priority call towards the ATS-QSIG network as specified in section 10.20.4 of ECMA-312 [33]. Having selected the call to be interrupted, the Gateway SHALL inform the parties involved that the call is to be released; an ATS-QSIG NOTIFY message containing the notification value “InterruptionIsImpending” SHALL be sent to the ATS-QSIG End (party in the circuit-switched network) and a SIP INFO message including a Text/Plain body indicating “Interruption is impending” SHALL also be sent to the SIP End (party in the IP-network). The Gateway SHALL also start the “Interruption pending” timer.

© EUROCAE, 2012

84

On expiry of the Interruption pending timer, the Gateway SHALL send an ATS-QSIG DISCONNECT message containing the notification value “InterruptionForcedRelease” to the ATS-QSIG_End and a SIP BYE request containing a Reason header as defined in [35] with the following content:

Reason: WG-67; cause=1001; text=”Emergency - Forced Release”

When clearing of the interrupted call has been completed, the Gateway SHALL continue the establishment of the priority call using the newly available B-channel.

6.7.2.2 Priority Call Interruption from ATS-QSIG to SIP

6.7.2.2.1 Receipt of a NOTIFY message containing notification value “InterruptionIsImpending”

On receipt of an ATS-QSIG NOTIFY message containing Notification value “InterruptionIsImpending” from the ATS-QSIG network, the Gateway SHALL send a SIP INFO message including a Text/Plain body indicating “Interruption is impending” to the SIP End.

6.7.2.2.2 Receipt of a DISCONNECT message containing notification value “InterruptionForcedRelease”

On receipt of an ATS-QSIG DISCONNECT message containing Notification value “InterruptionForcedRelease”, the Gateway SHALL send a SIP BYE request containing a Reason header as defined in [35] with the following content:

Reason: WG-67; cause=1001; text=”Emergency - Forced Release”

6.7.2.2.3 Receipt of a NOTIFY message containing notification value “InterruptionTerminated”

On receipt of an ATS-QSIG NOTIFY message containing Notification Value “InterruptionTerminated” from the ATS-QSIG network, the Gateway SHALL send a SIP INFO message including a Text/Plain body indicating “Interruption Terminated” to the SIP End.

6.7.3 Priority Call Intrusion

6.7.3.1 Priority Call Intrusion from ATS-QSIG to SIP

An ATS-QSIG Priority call (having CPICL = 3, CPIPL = 3 and CICL = 3) made towards an Incoming Gateway SHALL cause Gateway SIP User Agent to send SIP INVITE with a Priority header defined as “emergency” to distinguish it from a routine call (with Priority header defined as “urgent”, “normal”, “non-urgent”). If Intrusion is allowed (i.e. CIPL=0) by the Wanted SIP End User, the Wanted SIP End User will then act as the focus for the conference (use is made of the “isfocus” feature, defined in RFC 3840 [16] to create a conference media session). On receiving SIP 182 (Queued) provisional response, the Gateway SHALL send an ATS-QSIG ALERTING message toward the ATS-QSIG End. On receiving SIP 183 (Intrusion in progress) provisional response, the Gateway SHALL send an ATS-QSIG NOTIFY message indicating “intrusionIsImpending” to the ATS-QSIG End. If after a SIP 182 (Queued) provisional response, a SIP 200 (OK) response is received, the Gateway SHALL send an ATS-QSIG CONNECT message containing a Facility information element of type ciError indicating “NotAuthorised” to the ATS-QSIG End. If after a SIP 183 (Intrusion in progress) provisional response, a SIP 200 (OK) response is received, the Gateway SHALL send an ATS-QSIG CONNECT message containing a Facility information element of type ciRequest.res indicating “unwantedUserIntruded” to the ATS-QSIG End.

© EUROCAE, 2012

85

If intrusion is forbidden (i.e. CIPL=3), the Wanted user will reply with a SIP 180 (Ringing) response. Wanted and Unwanted users remain connected; The call from the ATS-QSIG user is displayed at the user’s terminal as a Priority Call and can be manually answered. On receiving a SIP 180 (Ringing) response, the Gateway SHALL send an ATS-QSIG ALERTING message containing a Facility information element of type ciError indicating “notAuthorised” to the ATS-QSIG End. Once an intrusion is effective, if the Unwanted User leaves the conference, the Gateway will receive a SIP INFO request including a Text/Plain body indicating “Intrusion completed”. On receipt of the SIP INFO request (“Intrusion completed”), the Gateway SHALL send an ATS-QSIG FACILITY message containing a facility information element “ciCompleted.inv” to the ATS-QSIG End (Served User).

6.7.3.2 Priority Call Intrusion from SIP to ATS-QSIG

On receipt of a SIP INVITE(emergency) request from the IP network, the Gateway SHALL attempt to establish a Priority call (ATS-QSIG SETUP message having CPICL = 3, CPIPL = 3 and CICL = 3) towards the ATS-QSIG network as specified in ECMA-312. The Gateway SHALL be configured to operate with T1 = 0 and automatic Priority call answer. If Intrusion is allowed (i.e. CIPL =0), the Wanted User (ATS-QSIG End) reply will be an ATS-QSIG NOTIFY message containing Notification Value “InterruptionIsImpending” and then an ATS-QSIG CONNECT message containing a Facility information element of type ciRequest.res indicating “unwantedUserIntruded”. On receipt of the ATS-QSIG NOTIFY message, the Gateway SHALL send a SIP 183 (Intrusion in progress) provisional response to the SIP End Served User. On receipt of the ATS-QSIG CONNECT message, the Gateway SHALL send a SIP 200 (OK) final response to the SIP End Served User. Once the intrusion is effective, the Gateway User Agent SHALL be ready to receive a dialog subscription from its SIP end-caller (Served User); it SHALL reply with a notification defining all parties in the conference media session, refer to Chapter 4.10 in [35]. If intrusion is forbidden (i.e. CIPL=3), the Wanted User reply will be an ATS-QSIG ALERTING message containing a Facility information element of type ciError indicating “notAuthorised”. On receipt of the ATS-QSIG ALERTING message, the Gateway SHALL send a SIP 180 (Ringing) response towards the IP-network. Once an intrusion is effective, if the Unwanted User leaves the conference, the Gateway will receive an ATS-QSIG FACILITY message containing a Facility information element of type “ciCompleted.inv”. On receipt of the ATS-QSIG FACILITY message containing a Facility information element “ciCompleted.inv”, the Gateway SHALL send a SIP INFO request including a Text/Plain body indicating “Intrusion completed”.

6.8 MESSAGE SEQUENCE CHARTS

The following paragraphs show some typical message sequences that can occur for an interworking between ATS-QSIG and SIP. The Message Sequence Charts (MSC) in the figures below show the information flows between the Call Control entity (labelled "Gateway") and respective Protocol Control entities for each signalling system (labelled "ATS-QIG_End" and "SIP_End") within a Gateway VCS. Each information flow is named according to the corresponding message or signal sent to or received from a peer VCS. Dashed lines (---) represent signalling messages that are mandatory to the call scenario. These messages can be SIP or ATS-QSIG signalling. The arrow indicates the direction of message flow. Double dashed lines (===) represent media paths between network elements.

© EUROCAE, 2012

86

6.8.1 Successful ATS-QSIG to SIP Routine Call

This is a typical message sequence for a successful call setup of an incoming routine call (to a gateway) from a route employing the ATS-QSIG signalling system which is routed on an IP network to the called user employing SIP.

ATS-QSIG_End Gateway Proxy SIP_End | | | | | SETUP | | | |--------------->| INVITE | | | CALL PROCEEDING|--------------->| INVITE | |<---------------| 100 Trying |--------------->| | |<---------------| | | | | 180 Ringing | | | 180 Ringing |<---------------| | ALERTING |<---------------| | |<---------------| | | | | | | | | | | | | | | | | | 200 OK | | | 200 OK |<---------------| | CONNECT |<---------------| | |<---------------| ACK | | | |--------------->| ACK | | | |--------------->| |(Both Way Voice)| (Both Way RTP Media) | |<==============>|<===============================>| | | | |

FIGURE 80: SUCCESSFUL ATS-QSIG TO SIP ROUTINE CALL

NOTE 20. For a routine call, CPIPL = 0, 1, 2 or 3, CPICL = 0 and CICL = 0, as indicated in Table 21.

NOTE 21. In accordance with section 10.9 of ECMA-312, on sending the CONNECT message a CONNECT ACKNOWLEDGE message will not be received.

© EUROCAE, 2012

87

6.8.2 Successful SIP to ATS-QSIG Routine Call

This is a typical message sequence for a successful call setup of an incoming routine call (to a gateway) from an IP network employing SIP which is routed on a route employing the ATS-QSIG signalling system.

ATS-QSIG_End Gateway Proxy SIP_End | | | | | | | INVITE | | | INVITE |<---------------| | SETUP |<---------------| 100 Trying | |<---------------| 100 Trying |--------------->| | CALL PROCEEDING|--------------->| | |--------------->| | | | ALERTING | | | |--------------->| 180 Ringing | | | |--------------->| 180 Ringing | | | |--------------->| | CONNECT | | | |--------------->| 200 OK | | | |--------------->| 200 OK | | | |--------------->| | | | ACK | | | ACK |<---------------| | |<---------------| | |(Both Way Voice)| (Both Way RTP Media) | |<==============>|<===============================>|

FIGURE 81: SUCCESSFUL SIP TO ATS-QSIG ROUTINE CALL

NOTE 22. For a routine call, the value of the “Priority” header field in the INVITE method shall be “urgent”, “normal” or “non-urgent”, as indicated in Table 22.

NOTE 23. In accordance with section 10.9 of ECMA-312, on receipt of the CONNECT message a CONNECT ACKNOWLEDGE message shall not be sent.

6.8.3 Normal Call Clearing from ATS-QSIG End

Typical message sequence for Call Clearing from ATS-QSIG to SIP subsequent to call establishment.

ATS-QSIG_End Gateway Proxy SIP_End | | | | |(Both Way Voice)| (Both Way RTP Media) | |<==============>|<===============================>| | | | | | DISCONNECT | | | |--------------->| BYE | | | RELEASE |--------------->| BYE | |<---------------| |--------------->| |RELEASE COMPLETE| | 200 OK | |--------------->| 200 OK |<---------------| | |<---------------| | | | | |

FIGURE 82: NORMAL CALL CLEARING FROM ATS-QSIG END

© EUROCAE, 2012

88

6.8.4 Normal Call Clearing from SIP End

Typical message sequence for Call Clearing from SIP to ATS-QSIG subsequent to call establishment.

ATS-QSIG_End Gateway Proxy SIP_End | | | | |(Both Way Voice)| (Both Way RTP Media) | |<==============>|<===============================>| | | | | | | | BYE | | | BYE |<---------------| | DISCONNECT |<---------------| | |<---------------| 200 OK | | | RELEASE |--------------->| 200 OK | |--------------->| |--------------->| |RELEASE COMPLETE| | | |<---------------| | | | | | |

FIGURE 83: NORMAL CALL CLEARING FROM SIP END

6.8.5 Unsuccessful ATS-QSIG to SIP Call

6.8.5.1 Call Clearing from ATS-QSIG End

This is a typical message sequence for Call Clearing from ATS-QSIG to SIP during establishment of a call from ATS-QSIG to SIP, in which the Gateway has received a provisional response (1xx) to the INVITE request but not a final response (2xx, 3xx, 4xx, 5xx, 6xx).

ATS-QSIG_End Gateway Proxy SIP_End | | | | | SETUP | | | |--------------->| INVITE | | | CALL PROCEEDING|--------------->| INVITE | |<---------------| 100 Trying |--------------->| | |<---------------| 180 Ringing | | | 180 Ringing |<---------------| | ALERTING |<---------------| | |<---------------| | | | DISCONNECT | | | |--------------->| CANCEL | | | RELEASE |--------------->| CANCEL | |<---------------| 200 OK |--------------->| |RELEASE COMPLETE|<---------------| 200 OK | |--------------->| |<---------------| | | |487 Req. Termin.| | |487 Req. Termin.|<---------------| | |<---------------| ACK | | | ACK |--------------->| | |--------------->| | | | | |

FIGURE 84: UNSUCCESSFUL ATS-QSIG TO SIP CALL. CALL CLEARING FROM ATS-QSIG END

© EUROCAE, 2012

89

6.8.5.2 Call Clearing from SIP Network

This is a typical message sequence for Call Clearing from SIP to ATS-QSIG during establishment of a call from ATS-QSIG to SIP, in which the Gateway has not previously received a final response (2xx, 3xx, 4xx, 5xx, 6xx) to the INVITE request.

ATS-QSIG_End Gateway Proxy SIP_End | | | | | SETUP | | | |--------------->| INVITE | | | CALL PROCEEDING|--------------->| INVITE | |<---------------| 100 Trying |--------------->| | |<---------------| 4xx-6xx | | | |<---------------| | | | ACK | | | 4xx-6xx |--------------->| | |<---------------| | | | ACK | | | DISCONNECT |--------------->| | |<---------------| | | | RELEASE | | | |--------------->| | | |RELEASE COMPLETE| | | |<---------------| | | | | | |

FIGURE 85: UNSUCCESSFUL ATS-QSIG TO SIP CALL. CALL CLEARING FROM SIP NETWORK

The mapping of the SIP responses to ATS-QSIG Cause values SHALL be as specified in ECMA-339.

6.8.6 Unsuccessful SIP to ATS-QSIG Call

6.8.6.1 Call Clearing from SIP Network

This is a typical message sequence for Call Clearing from SIP to ATS-QSIG during establishment of a call from SIP to ATS-QSIG, in which the Gateway has sent a provisional response (1xx) to the INVITE request but not a final response (2xx, 3xx, 4xx, 5xx, 6xx).

ATS-QSIG_End Gateway Proxy SIP_End | | | | | | | INVITE | | | INVITE |<---------------| | SETUP |<---------------| 100 Trying | |<---------------| 100 Trying |--------------->| |CALL PROCEEDING |--------------->| CANCEL | |--------------->| CANCEL |<---------------| | DISCONNECT |<---------------| 200 OK | |<---------------| 200 OK |--------------->| | RELEASE |--------------->| | |--------------->|487 Req. Termin.| | |RELEASE COMPLETE|--------------->| | |<---------------| ACK | | | |<---------------|487 Req. Termin.| | | |--------------->| | | | ACK | | | |<---------------| | | | |

FIGURE 86: UNSUCCESSFUL SIP TO ATS-QSIG CALL. CALL CLEARING FROM SIP NETWORK

© EUROCAE, 2012

90

6.8.6.2 Call Clearing from ATS-QSIG End

This is a typical message sequence for Call Clearing from ATS-QSIG to SIP during establishment of a call from SIP to ATS-QSIG, in which the Gateway has not sent a final response (2xx, 3xx, 4xx, 5xx, 6xx) to the INVITE request.

ATS-QSIG_End Gateway Proxy SIP_End | | | | | | | INVITE | | | INVITE |<---------------| | SETUP |<---------------| 100 Trying | |<---------------| 100 Trying |--------------->| |CALL PROCEEDING |--------------->| | |--------------->| | | | DISCONNECT | | | |--------------->| 4xx-6xx | | | RELEASE |--------------->| | |<---------------| ACK | | |RELEASE COMPLETE|<---------------| 4xx-6xx | |--------------->| |--------------->| | | | ACK | | | |<---------------| | | | |

FIGURE 87: UNSUCCESSFUL SIP TO ATS-QSIG CALL. CALL CLEARING FROM ATS-QSIG END

The mapping of the SIP responses to ATS-QSIG Cause values SHALL be as specified in ECMA-339.

6.8.6.3 Call Clearing from Gateway

This is a typical message sequence for Call Clearing from Gateway during establishment of a call from SIP to ATS-QSIG, in which the Gateway has not sent a final response (2xx, 3xx, 4xx, 5xx, 6xx) to the INVITE request, and ATS-QSIG protocol error is encountered by the Gateway during call set-up.

ATS-QSIG_End Gateway Proxy SIP_End | | | | | | | INVITE | | | INVITE |<---------------| | SETUP |<---------------| 100 Trying | |<---------------| 100 Trying |--------------->| |CALL PROCEEDING |--------------->| | |--------------->| | | | DISCONNECT | | | |<---------------|500 Svr.Int.Err.| | | RELEASE |--------------->|500 Svr.Int.Err.| |--------------->| ACK |--------------->| |RELEASE COMPLETE|<---------------| ACK | |<---------------| |<---------------| | | | |

FIGURE 88: UNSUCCESSFUL SIP TO ATS-QSIG CALL. CALL CLEARING FROM GATEWAY

© EUROCAE, 2012

91

6.8.7 Interworking of Supplementary Services

6.8.7.1 Priority Call Interruption

6.8.7.1.1 ATS-QSIG to SIP Priority Call Interruption

The message sequence shown below corresponds to a scenario in which a routine call, established through a gateway, is interrupted by a priority call from the ATS-QSIG_End.

ATS-QSIG_End Gateway SIP_EndProxy

NOTIFY “InterruptionIsImpending”

Both-way Voice Conference media session: 2 parties

DISCONNECT “InterruptionForcedRelease” BYE

“Emergency Forced Released”

200 OK200 OK

RELEASE

RELEASE COMPLETE

BYE“Emergency Forced Released”

CALL PROCEEDING

SETUP (cpiRequest.invoke)Priority Call INVITE (emergency)

100 Trying

InterruptPendingTimer T1

CALL PROCEEDING

SETUP (cpiRequest.invoke)Priority Call

ATS QSIG Priority call Proceeds on interruptedchannel

Congestion on Inter-VCS linkInterrupt lowest protected call

Start Timer T1

INFO“Interruption is impending” INFO

“Interruption is impending”200 OK

200 OK

FIGURE 89: ATS-QSIG TO SIP PRIORITY CALL INTERRUPTION

© EUROCAE, 2012

92

6.8.7.1.2 ATS-QSIG to SIP Priority Call Interruption Abandon

The message sequence shown below correspond to a scenario in which during the interrupt warning period another channel becomes available and it is used to establish the priority call.


NOTIFY “InterruptionIsImpending”

Both-way Voice Conference media session: 2 parties

NOTIFY “InterruptionTerminated”InterruptPendingTimer T1

CALL PROCEEDING


CALL PROCEEDING

SETUP (cpiRequest.invoke)Priority Call INVITE (emergency)

100 Trying

Interrupt Abandoned as another Channel available during “Interrupt pending” time.

ATS QSIG Priority call Proceeds on another channel



200 OK

INFO“Interruption Terminated” INFO

“Interruption Terminated”200 OK

200 OK

FIGURE 90: ATS-QSIG TO SIP PRIORITY CALL INTERRUPTION ABANDON

© EUROCAE, 2012

93

6.8.7.1.3 SIP to ATS-QSIG Priority Call Interruption

The message sequence shown below corresponds to a scenario in which a routine call, established through a gateway, is interrupted by a priority call from the SIP Network. An established routine call between SIP_End1 and ATS-QSIG_End1 across a gateway could be interrupted if an emergency call from SIP_End2 to ATS-QSIG_End2 finds congestion on the Gateway to ATS-QSIG_End1 link and decides to interrupt.

ATS-QSIG_End1 Gateway

SIP_End2

Proxy

NOTIFY “InterruptIsImpending”

Both-way Voice

Low Protected Call

RELEASE

RELEASE COMPLETE

CALL PROCEEDING


INVITE (emergency)

100 Trying

INVITE (emergency)

100 Trying

T1

DISCONNECT“InterruptForcedRelease”

ATS QSIG Priority call Proceeds on interruptedchannel

Congestion on Inter-VCS linkInterrupt lowest protected call

Start Timer T1

Conference media session: 2 parties

SIP_End1


200 OK200 OK


ATS-QSIG_End2

200 OK (invite)200 OK (invite)ACKACK

CONNECT

Conference Media Session: 2 parties Both Way Voice



200 OK

FIGURE 91: SIP TO ATS-QSIG PRIORITY CALL INTERRUPTION

© EUROCAE, 2012

94

6.8.7.1.4 SIP to ATS-QSIG Priority Call Interruption Abandon

The message sequence shown below correspond to a scenario in which during the interrupt warning period another channel becomes available and it is used for the priority call.


NOTIFY “InterruptIsImpending”

Both-way Voice

CALL PROCEEDING


INVITE (emergency)

100 Trying

INVITE (emergency)

100 Trying

InterruptPendingTimer T1

NOTIFY“InterruptTerminated”

Interrupt Abandoned as another Channel available during “Interrupt pending” time.

ATS QSIG Priority call Proceeds on availablechannel

FIGURE 92: SIP TO ATS-QSIG PRIORITY CALL INTERRUPTION ABANDON

© EUROCAE, 2012

95

6.8.7.2 Priority Call Intrusion

6.8.7.2.1 Priority Call at an Incoming Gateway

ATS-QSIG_End(Served User)

SETUP (ciRequest.inv, CICL=3)

GatewaySIP UA

B (Focus)SIP UA

C (Unwanted User)

Media Session

CALL PROCEEDINGINVITE (emergency)

200 OK

182 Queued

BYE

ACKCONNECT (ciRequest.error

NotAuthorised”)

Two Way Voice

Priority call answered within a predetermined time interval T1

ALERTING

200 OK

T < T1

Call is automatically or manually answered

FIGURE 93: ATS-QSIG TO SIP PRIORITY CALL ANSWERED AFTER RELEASING PREVIOUS CALL



GatewaySIP UA

B (Focus)SIP UA

C (Unwanted User)

Media Session

CALL PROCEEDING INVITE (emergency)

182 Queued


200 OK





ACK

Two Way Voice

Successful ATS-QSIG End Intrusion to SIP UA

NOTIFY ‘intrusionIsImpending’

200 OK

T1

ACK

ALERTING

CONNECT (ciRequest.res,user intruded)

FIGURE 94: ATS-QSIG TO SIP SUCCESSFUL PRIORITY CALL INTRUSION

© EUROCAE, 2012

96



GatewaySIP UA

B (Focus)SIP UA

C (Unwanted User)

Media Session

CALL PROCEEDINGINVITE (emergency)

reINVITE Contact B;isfocus (intrusion)

200 OK





ACK


Two Way Voice

Successful ATS-QSIG End Intrusion to SIP UA


200 OK

ACK

SIP UA B configured for an immediate automatic Priority call answer (T1 = 0)

FIGURE 95: ATS-QSIG TO SIP SUCCESSFUL PRIORITY CALL INTRUSION WITH T1 = 0

SIP_End1 Call intrusion Protection-ON

Both Way Voice



200 OK200 OK

ACKACK


Priority call is displayed at SIP_End1 and manually answered

Call displayed as Priority call at SIP_End1

CONNECT

SETUP (ciRequest.invoke)

CALL PROCEEDING

ALERTING (ciRequest.error NotAuthorised”)


Priority Header =normal

Priority Call


ATS-QSIG_End(Served User) Gateway SIP_End1

(Wanted User)SIP_End2

(Unwanted User)Proxy

FIGURE 96: ATS-QSIG TO SIP PRIORITY CALL INTRUSION FORBIDDEN BY WANTED USER

© EUROCAE, 2012

97

• The Call Intrusion Protection Level of the Unwanted User shall be assumed as 0 (OFF), that is call intrusion permitted, or not, determined exclusively by the Wanted User; there is no SIP signalling for SIP_End2 (Unwanted User) to forbid call intrusion.

• Call intrusion will happen unless the established active call is a Priority call (Priority header field = “emergency”).

FIGURE 97: ATS-QSIG TO SIP PRIORITY CALL INTRUSION CANNOT BE FORBIDDEN BY UNWANTED USER



200 OK200 OK

ACKACK


Priority call is displayed at SIP_End1 and manually answered

Call indicated as Priority call at SIP_End1

CONNECT

CALL PROCEEDING

ALERTING (ciRequest.error “NotAuthorised”)


Priority Header =emergencyl

SETUP (ciRequest.invoke)Priority Call

Both Way Voice Media Session: 2 parties




FIGURE 98: ATS-QSIG TO SIP PRIORITY CALL INTRUSION INTO ANOTHER PRIORITY CALL FORBIDDEN

© EUROCAE, 2012

98

DISCONNECT

Conference Media Session: 3 partiesBoth Way Voice

BYEBYE

200 OK200 OK

RELEASE

RELEASE COMPLETE

200 OK





ACK

FIGURE 99: CALL CLEARING BY ATS-QSIG END

ATS-QSIG_End(Served User) Gateway

SIP UAB (Focus)

SIP UAC (Unwanted User)

Media Session

reINVITE Contact B

200 OKMedia Session terminated

BYE

200 OK

Both Way Voice

Call Clearing by Unwanted SIP UA

INFO “intrusion completed”

FACILITY ciCompleted.inv”200 OK

ACK

FIGURE 100: CALL CLEARING BY UNWANTED USER

© EUROCAE, 2012

99

6.8.7.2.2 Priority Call at an Outgoing Gateway

Both-way Voice

INVITE (emergency)

100 Trying

SIP UA(Served User)

ATS-QSIG_End1(Wanted User)

ATS-QSIG_End2(Unwanted User)Gateway

200 OK

ACK

Successful SIP UA Intrusion to ATS-QSIG End


Media session


CALL PROCEEDINGFACILITY (ciGetCIPL.inv)

FACILITY (ciGetCIPL.res)




NOTIFY ‘intrusionIsEffective’

FIGURE 101: SIP TO ATS-QSIG SUCCESSFUL PRIORITY CALL INTRUSION

Both-way Voice

CONNECT

INVITE (emergency)INVITE (emergency)

100 Trying

200 OK200 OK

ACKACK

Call is manually answered

100 Trying

Both Way Voice

CALL PROCEEDING

ALERTING (ciRequest.error “NotAuthorised”)180 Ringing180 Ringing

Routine call

ATS-QSIG End1 Call intrusion Protection ON

ATS-QSIG End1 decides Call intrusion can’t proceed



Priority call is displayed at ATS-QSIG End1 and manually answered

SIP_End(Served User) Proxy ATS-QSIG End1

(Wanted User)ATS-QSIG End2(Unwanted User)Gateway

FIGURE 102: SIP TO ATS-QSIG PRIORITY CALL INTRUSION FORBIDDEN BY WANTED USER

© EUROCAE, 2012

100

Both-way Voice

CONNECT


100 Trying

200 OK200 OK

ACKACK

Priority call is displayed at ATS-QSIG End1 and manually answered


100 TryingCALL PROCEEDING

ALERTING (ciRequest.error “NotAuthorised”)180 Ringing180 Ringing

SIP_End(Served User)

ATS-QSIG End1(Wanted User)

ATS-QSIG End2(Unwanted User)

Proxy Gateway

Priority call

ATS-QSIG End1 Call intrusion Protection OFF

ATS-QSIG End1 decides Call intrusion can’t proceed into an active Priority call


Both Way VoiceMedia Session: 2 parties

FIGURE 103: SIP TO ATS-QSIG PRIORITY CALL INTRUSION INTO ANOTHER PRIORITY CALL FORBIDDEN

NOTIFY “endOfIntrusion”

BYEBYE

200 OK200 OK

Both-way Voice

Conference Media Session: 2 parties Both Way Voice Both-way Voice

DISCONNECT

RELEASE

RELEASE COMPLETE



FIGURE 104: CALL CLEARING BY SIP UA

© EUROCAE, 2012

101

DISCONNECT

Both Way Voice Both-way Voice

Both Way Voice

RELEASE COMPLETE

RELEASEFACILITY “ciCompleted.inv”INFO “Intrusion completed”

200 OK

INFO “Intrusion completed”

200 OK





FIGURE 105: CALL CLEARING BY UNWANTED ATS-QSIG END

CONNECT


100 Trying

200 OK200 OK

ACKACK


100 TryingCALL PROCEEDING

ALERTING ciRequest.error “Not Busy”180 Ringing180 Ringing

ATS-QSIG End1 Call intrusion Protection ON or OFF

Automatic connection of Priority Call is not allowed

SIP_End(Served User)

ATS-QSIG End1(Wanted User)

ATS-QSIG End2(Unwanted User)Proxy Gateway

ATS-QSIG End1 has no active call


Media Session: 2 parties Both Way Voice

FIGURE 106: SIP TO ATS-QSIG PRIORITY CALL INTRUSION TO A NON-BUSY WANTED USER

© EUROCAE, 2012

102

ANNEX A

REFERENCES

[1] RFC 768: “User Datagram Protocol”, August 1980. [2] RFC 791: “Internet Protocol”, September 1981. [3] RFC 793: “Transmission Control Protocol”, September 1981. [4] RFC 2046: “Multipurpose Internet Mail Extensions (MIME) Part Two: Media

Types", November 1996. [5] RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels",

BCP 14, March 1997. [6] RFC 2460: “Internet Protocol, Version 6 (IPv6) Specification”, December

1998 [7] RFC 2976: “The SIP INFO Method”, October 2000. [8] RFC 3261: “SIP: Session Initiation Protocol”, June 2002. [9] RFC 3264: “An Offer/Answer Model with the Session Description Protocol

(SDP)”, June 2002. [10] RFC 3265: “Session Initiation Protocol (SIP)-Specific Event Notification”,

June 2002. [11] RFC 3398: “Integrated Services Digital Network (ISDN) User Part (ISUP) to

Session Initiation Protocol (SIP) Mapping”, December 2002. [12] RFC 3428: “Session Initiation Protocol (SIP) Extension for Instant

Messaging”, December 2002. [13] RFC 3515: “The Session Initiation Protocol (SIP) Refer Method”, April 2003. [14] RFC 3550: “RTP: A Transport Protocol for Real-Time Applications”, July

2003. [15] RFC 3665: Session Initiation Protocol (SIP) Basic Call Flow Examples,

December 2003. [16] RFC 3666: “Session Initiation Protocol (SIP). Public Switched Telephone

Network (PSTN) Call Flows”, December 2003. [17] RFC 3676: "The Text/Plain Format and DelSp Parameters", February 2004. [18] RFC 3840: “Indicating User Agent Capabilities in the Session Initiation

Protocol (SIP)”, August 2004. [19] RFC 3856: “A Presence Event Package for the Session Initiation Protocol

(SIP)”, August 2004. [20] RFC 3863: “Presence Information Data Format (PIDF)”, August 2004. [21] RFC 3891: “The Session Initiation Protocol (SIP) ‘Replaces’ Header”,

September 2004. [22] RFC 3911: “The Session Initiation Protocol (SIP) ‘Join’ Header”, October

2004. [23] RFC 4235: “An INVITE-Initiated Dialog Event Package for the Session

Initiation Protocol (SIP)”, November 2005. [24] RFC 4346: “The Transport Layer Security (TLS) Protocol - Version 1.1”, April

2006. [25] RFC 4566: “SDP: Session Description Protocol”, July 2006. [26] RFC 4575: “A Session Initiation Protocol (SIP) Event Package for

Conference State”, August 2006. [27] RFC 4579: “Session Initiation Protocol (SIP) Call Control – Conferencing for

User Agents”, August 2006. [28] RFC 5359: “Session Initiation Protocol Service Examples”, October 2008. [29] Eurocontrol. “ATS R2 and ATS No.5 Signalling Protocol Specifications”, Ed.

1.0 (February 2005).

© EUROCAE, 2012

103

[30] ITU-T. Rec. G.711. “Pulse Code Modulation (PCM) of Voice Frequencies”, November 1988.

[31] ITU-T. Rec. G.728. “Coding of Speech at 16 Kbit/s Using Low-delay Code Excited Linear Prediction”, September 1992.

[32] ECMA-143: “Private Integrated Services Network (PISN); Circuit Mode Bearer Services; Inter-Exchange Signalling Procedures and Protocol (ISO/IEC 11572)”.

[33] ECMA-312: “Private Integrated Services Network (PISN); Profile Standard for the Use of PSS1 (QSIG) in Air Traffic Services Networks”.

[34] ECMA-339: “Corporate Telecommunication Networks; Signalling Interworking between QSIG and SIP; Basic Services”.

[35] EUROCAE ED-137 “Interoperability Standards for VoIP ATM Components, Volume 2: Telephone.”

© EUROCAE, 2012

104

ANNEX B

ACRONYMS

Ack Acknowledge AGVN Air Traffic Services Ground Voice communications Network A/G Air/Ground AM Amplitude Modulation ANSP Air Navigation Service Provider ATA Analogue Telephone Adapter ATC Air Traffic Control ATM Air Traffic Management ATS Air Traffic Services ATS-No.5 Air Traffic Services – No.5 signalling system ATS-QSIG Air Traffic Services – Q reference point SIGnalling system ATS-R2 Air Traffic Services – R2 signalling system AVP Audio/Video Profile CICL Call Intrusion Capability Level CIPL Call Intrusion Protection Level CPICL Call Priority Interruption Capability Level CPIPL Call Priority Interruption Protection Level CWP Controller Working Position DA Direct Access DNS Domain Name Service ECMA European Computer Manufacturers Association G/G Ground/Ground HMI Human Machine Interface HTTP HyperText Transfer Protocol IA Instantaneous Access IANA Internet Assigned Numbers Authority ICCVC Instantaneous Controller-Controller Voice Communication IDA InDirect Access IETF Internet Engineering Task Force IP Internet Protocol ISDN Integrated Services Digital Network ITU-T International Telecommunication Union – Telecommunication

standardization sector LAN Local Area Network LD-CELP Low Delay - Code Excited Linear Prediction MF Multi-Frequency MFC Multi-Frequency Code MSC Message Sequence Chart N. A. Not Applicable PABX Private Automatic Branch eXchange PCM Pulse Code Modulation PINX Private Integrated services Network eXchange PISN Private Integrated Services Network PSS1 Private Signalling System no. 1

© EUROCAE, 2012

105

PSTN Public Switched Telephone Network QoS Quality of Service Rec. Recommendation RFC Request For Comments RTCP Real-time Control Protocol RTP Real-time Transport Protocol Rx Reception S/MIME Secure / Multipurpose Internet Mail Extensions SDP Session Description Protocol SIP Session Initiation Protocol SS-IA Instantaneous Access Supplementary Service TCP Transmission Control Protocol TDM Time Division Multiplexing TLS Transport Layer Security TU Transaction User Tx Transmission UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Universal Resource Identifier UHF Ultra-High Frequency VCS Voice Communications System VHF Very High Frequency VoIP Voice over the Internet Protocol WAN Wide Area Network

© EUROCAE, 2012

106

© EUROCAE, 2012

ANNEX C

LIST OF EUROCAE WG-67 CONTRIBUTORS


ADRIAN Andre DFS

BARABAN Luc CSSI

BICA Dumitru ROHDE & SCHWARZ TOPEX

GELADA Mario ATIS


MARTÍN Miguel A. AENA

PABLOS Sergio INDRA SISTEMAS

PALMER John S. JSP-TELECONSULTANCY

POTIRON Guy DSNA, EUROCAE WG67 CHAIRMAN

SMITH Barry FAA


WEGER Roberto SITTI


Interoperability Standards for VoIP ATM Components - … · The document ED-137 Volume 1...

Documents

Transcript of Interoperability Standards for VoIP ATM Components - … · The document ED-137 Volume 1...