next generation icao 9896 voip interfaces for ats ground voice network - part 3

Copyright 2014 JSP-Teleconsultancy 1

Next Generation ICAO 9896 VoIP interfaces for ATS Ground Voice Network - Part 3

Training Documentation

Produced by JSP Teleconsultancy 1

Copyright Notice

2014 JSP Teleconsultancy . All rights reserved.

JSP Teleconsultancy has the exclusive rights to present Air Traffic Services Ground Voice Network Communication courses, including ATS-QSIG courses under a Licence Agreement (L/01/03-JSP/QSIG) with EUROCONTROL Institute of Air Navigation Services. This documentation has been produced by JSP Teleconsultancy and may only be used in the framework of the Licence Agreement and/or in relation with the pertinent Eurocontrol courses, workshops and seminars. The reproduction of this material is permitted for personal and non-commercial purposes only. This is subject to the material being reproduced accurately and not used in a misleading context. This document or CD-ROM may be copied to third parties under the same restrictions, provided the source is acknowledged.

Any other use is subject to prior written consent by JSP Teleconsultancy.

Requests shall be addressed to: JSP Teleconsultancy, Via Gorizia, 11 FOLIGNANO, 63040, Ascoli Piceno, Italy.


Table of Contents

1. INTRODUCTION ............................................................................................................................. 7 Introduction to course ..................................................................................................................................... 8 Course Objectives - DAY 3 ............................................................................................................................. 8

2. ADDED BENEFITS VOIP BRINGS TO RECORDING EQUIPMENT .......................................... 11 ED-136 Recording Requirements (1) ........................................................................................................... 12 ED-136 Recording Requirements (2) ........................................................................................................... 14 ED-137B Volume 4 - Recording Requirements ............................................................................................ 16 ED-137B Volume 4 Recording Req (2) ......................................................................................................... 16 ED-137B Volume 4 -Recording Req (3) ....................................................................................................... 18 Recording Telephone Speech ...................................................................................................................... 18 Recording Radio Speech .............................................................................................................................. 20 ED-137B Volume 4 -Recording Req (4) ....................................................................................................... 20 ED-137B Volume 4 -Recording Req (5) ....................................................................................................... 22 Methodology for Voice recording .................................................................................................................. 24 Replay functionality ...................................................................................................................................... 26 Call detail records ......................................................................................................................................... 28 Basic Outgoing Call- Answered Example ..................................................................................................... 34 VCS-GRS-Recorder Interoperability Test Configuration ............................................................................... 36

3. NETWORK PERFORMANCE ASPECTS .................................................................................... 39

Call performance criteria for DA and IA ........................................................................................................ 40 One way Voice Delay for Telephone ............................................................................................................ 42 One way Voice Delay for Radio .................................................................................................................... 44 Voice Quality of A/G & G/G communications ............................................................................................... 46 Transmitter Activation Delay - A/C call indication delay ................................................................................ 50 Precedence level assignment of voice services ........................................................................................... 52 Voice packet duration to IP bandwidth ......................................................................................................... 54 Calculating Equivalent Bandwidth required in IPv6 networks ....................................................................... 56 Calculating IPv6 Equivalent Bandwidth required to Radio ............................................................................ 58 Supervision Model (ED-137B Volume 5 -Supervision) ................................................................................. 60 ED-137B/5 Supervision-Monitoring Functions .............................................................................................. 62 Supervision -SNMP data flow ....................................................................................................................... 64 VCS Supervision Structure within MIB ......................................................................................................... 66 VOTE SG1 solution for Basic Monitoring & Control of GRS ......................................................................... 72

4. VOIP IN ATM NETWORK ARCHITECTURE ............................................................................... 75 Technical Spec for provision of PENS .......................................................................................................... 76 ED-138 QoS Requirements .......................................................................................................................... 78 Platinum Service for Voice transport ............................................................................................................ 80 Network Connectivity, Quality and Performance, Availability issues ............................................................ 82 Class of Service (CoS) ................................................................................................................................. 84 PENS network architecture........................................................................................................................... 84

5. VOIP IN ATM NETWORK SECURITY ......................................................................................... 87 ED-137B Security Considerations ................................................................................................................ 88 ED-138 Network Security Model ................................................................................................................... 90 PENS core network security requirements ................................................................................................... 92 SIP User Agent authentication...................................................................................................................... 94


S/MIME Encryption ....................................................................................................................................... 96 Transmission Layer Security (TLS) .............................................................................................................. 98 What is IPsec? ............................................................................................................................................ 100 IPsec overview ........................................................................................................................................... 102 IP security (IPSec) ...................................................................................................................................... 104 Voice encryption aspects ............................................................................................................................ 108 End-to-End delay budget for Real time voice with IPSec ........................................................................... 108

6. EUROCONTROL TEST TOOL ................................................................................................... 111 EUROCONTROL Test Tool History ............................................................................................................ 112 VOTER tool installation on PC.................................................................................................................... 112 VOTER Tool installation on PC .................................................................................................................. 114 How to run the test suite ............................................................................................................................. 114 Test Case Analysis ..................................................................................................................................... 116

7. INTEROPERABILITY EVENTS OVERVIEW ............................................................................. 119 What are Plugtest Events? ......................................................................................................................... 120 Industry Driven VoIP interface Interoperability Testing ............................................................................... 122 Documents produced for event................................................................................................................... 126 Product Interoperability ............................................................................................................................... 128 Typical company pairing schedule .............................................................................................................. 130 Test Schedule Statistics ............................................................................................................................. 132 Interop events - Participating vendors ........................................................................................................ 132 Interoperability Event Network diagram ...................................................................................................... 134 FAA interop event-Radio test scenarios ..................................................................................................... 136 FAA interop event - Radio Gateway test scenarios .................................................................................... 136 FAA interop event - Telephone test scenarios ............................................................................................ 138 FAA interop event -Recorder test scenarios ............................................................................................... 138 VCS-GRS/RRC Result summary ................................................................................................................ 140 VCS-VCS Result summary ......................................................................................................................... 142 Recorder - VCS/GRS Result summary ....................................................................................................... 144 VoIP to Recorders ...................................................................................................................................... 146 Combined Result summary for Overall event ............................................................................................. 146 Performance measurements ...................................................................................................................... 148 Wireshark RTP HE Dissector Plugin .......................................................................................................... 148

8. NETWORK EMULATOR/PERFORMANCE MEASUREMENTS ............................................... 151 WAN Emulator and Network Simulation ..................................................................................................... 152 WAN Emulator Graphical User Interface .................................................................................................... 152 Network Impairment Emulation (1) ............................................................................................................. 154 Network Impairment Emulation (2) ............................................................................................................. 156 Impairments, Modifiers, Interfaces, Filters .................................................................................................. 158 Call Performance Test Infrastruture ............................................................................................................ 158 Voice Delay Measurement of WAN ............................................................................................................ 160 FAA VoIP_IE- Network Impairment Measurements .................................................................................... 162 Monitoring Tool ........................................................................................................................................... 162 BW for VCS to Radio .................................................................................................................................. 164 BW for VCS to RRC ................................................................................................................................... 164 R2S-Keep-alive messages ......................................................................................................................... 166 BW for VCS to VCS calls ............................................................................................................................ 166 Multiple VCS to VCS calls .......................................................................................................................... 168 BW for VCS to Recorder ............................................................................................................................ 168 VoIP voice quality & latency measurements ............................................................................................... 170


Voice Latency Measurements .................................................................................................................... 170 PTT latency measurements ........................................................................................................................ 172 Voice Quality Measurements ...................................................................................................................... 172 CWP to RRC/GRS- One-way voice delay .................................................................................................. 174 CWP to RRC/GRS - Round Trip voice delay .............................................................................................. 174 CWP to CWP Voice Delay .......................................................................................................................... 176 CWP to RRC/GRS -PTT delay ................................................................................................................... 176 CWP to CWP/RRC/GRS - Voice Quality .................................................................................................... 178 SESAR 15.2.10 D11/D12 Telephony result overview ................................................................................. 180 SESAR 15.2.10 D12 Radio results overview .............................................................................................. 186 Climax Dynamic Delay Compensation Tests .............................................................................................. 190

GLOSSARY ........................................................................................................................................ 193


Next Generation ICAO 9896 VoIP interfaces for ATS Ground Voice Network

- Part 3

Introduction


1. Introduction


Introduction to course

Course Objectives - DAY 3

Introduction




- Part 3

Added benefits VoIP brings to Recording equipment


2. Added benefits VoIP brings to Recording equipment


ED-136 Recording Requirements (1)

ED-136 Recording Requirements

Legal Recording Requirements: Recording ATC comms SHALL adhere to ICAO Annex 10, Volume II, Chapter 3.5;

True and faithful representation of audio signal: Voice Recording System SHALL, at all times, provide a

means for recording voice which is a true & faithful representation of audio signals being presented.

o Recorded audio identical to audio at recording point. o Audio quality not degraded nor improved. o Lost packet regeneration, post-processing techniques or transcoding NOT to be performed by

RTSP server.

Provision for 2 identical autonomous voice recordings: Voice Recording system SHALL provide means for

2 autonomous and identical voice recordings can be made. (Implies Main/Backup RTSP servers at same

recording point).

Date & Timestamp Synchronization: For purposes of imprinting date & timestamp info with recorded voice

(so time & date of re-played voice & Call Record Events can be precisely identified), Voice Recording System

SHALL be synchronous with Universal Time Coordinated (UTC) date/time data source to accuracy specified

by ICAO Convention on International Civil Aviation, Annex 5: Units of Measurement to be Used in Air and Ground Operations. (i.e. YYYY-MM-DD_HH:MM:SS.XXX+0000) (timestamp resolution 1ms).

Recording location: SHALL be clearly identified during audio recording replay.

Voice recording all communications at CWP: Provisions SHALL be made to enable the recording of all

communications at position level.

Entities for voice recording and location identification: Voice Recording System SHALL provide means by

which recordings SHALL be made of voice messages at following entities: a specific CWP, a specific radio

receiver; a specific radio transmitter; a specific 3rd party.



ED-136 Recording Requirements (1)

Legal Recording Requirements: Recording ATC commsSHALL adhere to ICAO Annex 10, Volume II, Chapter 3.5;

True and faithful representation of audio signal: Voice Recording System SHALL, at all times, provide a means for

recording voice which is a true & faithful representation of audio

signals being presented.

Recorded audio identical to audio at recording point.

Audio quality not degraded nor improved.

Lost packet regeneration, post-processing techniques or transcoding NOT to be performed by RTSP server.

Provision for 2 identical autonomous voice recordings: Voice Recording system SHALL provide means for 2 autonomous and

identical voice recordings can be made. (Implies Main/Backup

RTSP servers at same recording point).


ED-136 Recording Requirements (2) Date & Timestamp Synchronization: For purposes of imprinting date & timestamp info with recorded voice

(so time & date of re-played voice & Call Record Events can be precisely identified), Voice Recording System

SHALL be synchronous with Universal Time Coordinated (UTC) date/time data source to accuracy specified

by ICAO Convention on International Civil Aviation, Annex 5: Units of Measurement to be Used in Air and Ground Operations. (i.e. YYYY-MM-DD_HH:MM:SS.XXX+0000) (timestamp resolution 1ms).

The UTC timestamps defined by RECORD, PAUSE, SET_PARAMETER and TEARDOWN CRD XML body

messages SHALL take the following format:

YYYY-MM-DD_HH:MM:SS.XXX+0000

YYYY = year, four digits

MM = month, two digits

DD = day, two digits

HH = hours, two digits

MM = minutes, two digits

SS = seconds, two digits

XXX = milliseconds, three digits

+0000 MUST be always fixed since the time stamp sent to the REC is in UTC format no matter what local time is in client equipment

Example:

2011-05-16_08:30:30.123+0000


Voice recording all communications at CWP: Provisions SHALL be made to enable the recording of all

communications at position level.

Entities for voice recording and location identification: Voice Recording System SHALL provide means by

which recordings SHALL be made of voice messages at following entities: a specific CWP, a specific radio

receiver; a specific radio transmitter; a specific 3rd party.



ED-136 Recording Requirements (2) Date & Timestamp Synchronization: For purposes of imprinting date

& timestamp info with recorded voice (so time & date of re-played voice

& Call Record Events can be precisely identified), Voice Recording

System SHALL be synchronous with Universal Time Coordinated (UTC)

date/time data source to accuracy specified by ICAO Convention on

International Civil Aviation, Annex 5: Units of Measurement to be Used in Air and Ground Operations. (i.e. YYYY-MM-DD_HH:MM:SS.XXX+0000)

(timestamp resolution to 1ms accuracy, allowing distinction between voice messages).


Voice recording all communications at CWP: Provisions SHALL be made to enable the recording of all communications at position level.

Entities for voice recording and location identification: Voice Recording System SHALL provide means by which recordings SHALL

be made of voice messages at following entities: a specific CWP, a

specific radio receiver; a specific radio transmitter; a specific 3rd party.


ED-137B Volume 4 - Recording Requirements Recording entities: Voice SHOULD be recorded at following entities:

specific G/G I/F (Tx and Rx paths) at VCS endpoint; specific A/G I/F (Tx path) at VCS endpoint; specific A/G I/F (Rx path) at VCS endpoint.

Voice MAY be recorded voice at following entities:

specific radio Rx or radio GW (optional); specific radio TxRx or radio GW (optional); specific 3rd party.

Active Recording: SHALL be used, with session opened by CWP/VCS client, Radio Rx/TxRx/GW or 3

rd

party

to RTSP Server (Recorder equipment).

Provision of dual channels for CWP recording: (implies 2 independent RTSP sessions to one RTSP server)

Provision of at least 1 channel for GRS/RRCE recording with 2 channels (optional).

ED-137B Volume 4 Recording Req (2) Call Record Data (CRD):

G/G calls SHALL be sent at call initiation, call accept/refusal and call termination. outgoing A/G calls SHALL be sent at PTT activation & deactivation. Incoming A/C calls SHALL be sent at SQU activation & deactivation.

Packet size: 20ms (default), but RTSP server SHALL recognize & record audio packet sizes from 10ms to

80ms (duration). Packet size negotiation not used. Larger packet sizes reduce BW overhead towards RTSP

server.

QoS: Diffserv codepoint assigned to recording packets SHALL be configurable- but at least AF31 or better.

Audio codecs supported:

ITU-T Rec. G.711 PCM A-law ITU-T Rec. G.711 PCM mu-law ITU-T Rec. G.728 LD-CELP ITU-T Rec. G.729 CS-ACELP

No transcoding: RTSP server records compressed audio streams without transcoding audio.

Audio codecs negotiation: between Client and RTSP server during session establishment.

Encryption: Audio to RTSP server MAY be encrypted using 128Bit AES encoding. Any Encryption SHALL

use 128/256 Bit AES algorithm.

SIP: SIP session establishment to RTSP server is optional.

RTSP server registration: if SIP used, then SIP registration with SIP Registrar server SHOULD occur.



ED-137B Volume 4 - Recording Req

Recording entities: Voice SHOULD be recorded at following entities: specific G/G I/F (Tx and Rx paths) at VCS endpoint; specific A/G I/F (Tx path) at VCS endpoint; specific A/G I/F (Rx path) at VCS endpoint.

Voice MAY be recorded voice at following entities: specific radio Rx or radio GW (optional); specific radio TxRx or radio GW (optional); specific 3rd party.

Active Recording: SHALL be used, with session opened by CWP/VCS client, Radio Rx/TxRx/GW or 3rd party to RTSP

Server (Recorder equipment).

Provision of dual channels for CWP recording:(implies 2 independent RTSP sessions to one RTSP server)

Provision of at least 1 channel for GRS/RRCE recording with 2 channels (optional).

ED-137B Volume 4 Recording Req (2)

Call Record Data (CRD) SHALL be sent:

At call initiation/arrival, accept/refusal & termination for G/G calls.

At PTT-ON and OFF for Outgoing A/G calls.

At SQU-ON and OFF for Incoming A/G calls

Packet sizes: 10 to 80ms (20ms default) recognised by RTSP server. No packet size negotiation used.

QoS: DSCP value assigned as AF31 or better. Audio codecs supported: A-law, mu-law, LD-CELP & CS-ACELP Audio codecs negotiation: On RTSP session

establishment. No Transcoding of compressed audio during

Recording process.

Encryption: Audio MAY be encrypted-128Bit AES encoding. Any Encryption SHALL use 128/256 Bit AES algorithm.

SIP session optional: to RTSP server. If used Registration with Registrar server SHOULD occur.


ED-137B Volume 4 -Recording Req (3)

ED-137B/4 Recording: Defines 2 Transport methods:

1st RTP over independent TCP (default) has been tested, (allows RTSP signaling and RTP media to be split on different sockets).

2nd Embedded (interleaved) Binary Data: combines RTP/RTSP on same socket.

Audio Transport: RTP over TCP (for guaranteed delivery)

RTP-HE: VCS/Radio client MAY include RTP-HE in RTP stream sent to RTSP server.

RTP with RTCP: VCS/Radio client SHALL use RTP only and MAY use RTP with RTCP.

Signalling transport: RTSP over TCP.

RTSP server ports: SHALL be 554 for both TCP & UDP.

RTSP server address: All RTSP servers have an address.

(i.e. rtsp://ANSP-recorder2:554/iprecorder/ RTSP/1.0)

Address Permission list: SHALL be enabled/disabled at RTSP server, checked before accepting session

requests from client addresses.

OPTIONS request supported by RTSP server.

Recording Telephone Speech

Recording Model for Telephone communication

User Terminals participating in a G/G communication session SHALL generate a single RTP audio stream

containing the sum of the incoming (IN) and outgoing (OUT) audio streams at the position. It SHALL establish

dual RTSP sessions with its nominated RTSP server per G/G communication for redundancy purposes. The

summed RTP audio stream SHALL be transported over both RTSP sessions towards its nominated RTSP

server.

VCS network interfaces participating in a G/G communication session SHOULD generate a single RTP audio

stream containing the sum of all incoming (IN) and outgoing (OUT) audio streams at the interface. It SHOULD

establish a single RTSP session with its nominated RTSP server per G/G communication and MAY establish

dual RTSP sessions with its nominated RTSP server for redundancy purposes.




ED-137B/4 Recording: Defines 2 Transport methods: 1) RTP over independent TCP (default) has been tested, (allows

RTSP signaling and RTP media to be split on different sockets).

2) Embedded (interleaved) Binary Data: combines RTP/RTSP on same socket.

Audio Transport: RTP over TCP (for guaranteed delivery); RTP-HE: VCS/Radio client MAY include RTP-HE in RTP

stream sent to RTSP server.

RTP with RTCP: VCS/Radio client SHALL use RTP only and MAY use RTP with RTCP.

Signalling transport: RTSP over TCP. RTSP server ports: SHALL be 554 for both TCP & UDP. RTSP server address: All RTSP servers have an address.

(i.e. rtsp://ANSP-recorder2:554/iprecorder/ RTSP/1.0)

Address Permissions list: enabled/disabled at RTSP server; OPTIONS request supported by RTSP server.

Recording Telephone Speech

Recording based on Active sessions opened by VCS or CWP UAs to 2 recording devices (for redundancy);

At instant of outgoing or incoming call connection, VCS or CWP UA has responsibility of sending single audio stream (i.e.sum of IN &

OUT audio streams) to Recorder;

Recommended to use RTSP over TCP as reliable delivery service;

Time source used synchronized to UTC with ICAO accuracy. Timestamps sent by VCS or CWP UAs within RTP packets

VCS

Client

User Terminal

Client

VCS

Client

User Terminal

Client

IP Network

Audio OUTAudio OUT

Audio IN Audio IN

Recorder

Server

Audio IN+OUT Audio IN+OUT


Recording Radio Speech

Recording Model for Radio communication

User Terminals participating in an A/G communication session SHALL generate a single RTP audio stream

containing the sum of all received (Rx) and transmitted (Tx) audio at the position from all configured

frequencies. It SHALL establish dual RTSP sessions with its nominated RTSP server for redundancy purposes.

The summed RTP audio stream SHALL be transported over both RTSP sessions towards its nominated RTSP

server.

VCS network interfaces participating in an A/G communication session SHOULD generate a single RTP audio

stream that contains either received (Rx) audio on the specific frequency and/or transmitted (Tx) audio on the

specific frequency. It SHOULD establish a single RTSP session with its nominated RTSP server and MAY

establish dual RTSP sessions with its nominated RTSP server for redundancy purposes.

Note

It should be noted that recording audio on the Receive path only from a Radio Receiver will also include

transmitted audio due to the radio receiver(s) picking-up the off-air transmitted audio from its associated Radio

Transmitter. Transmitted audio recorded on the receive path is also proof that the audio was actually

transmitted.

Radios (or Radio Gateways connecting legacy radios to an IP network) MAY provide a single audio stream that

contains either the received (Rx) audio stream related to a single radio channel (applied to Radio Receivers

only) or the summed transmit and receive (Rx+Tx) audio stream related to a single radio channel (applied to

Radio Transceivers only).


RTSP session teardown: RTSP server should not close session (even after receiving Teardown command),

until all audio packets have stopped arriving.

Bandwidth to RTSP server SHALL be sufficient to ensure packet drop do not occur due to congestion.

RTSP session for G/G comms: 1

st

G/G call causes RTSP session to be established. Other concurrent calls at

CWP (i.e. OVR, IA, Intrusion, DA call), keep the same RTSP session. Audio from all parties summed and sent

to RTSP server. RTSP session terminated when last call ends.

RTSP session for A/G comms: RTSP session established when the 1st frequency configured at CWP. With

addition of further frequencies, the same RTSP session is used. Summed audio from all frequencies sent to

RTSP server. RTSP session cleared when last frequency unconfigured.

Rx voting: Audio from voted receiver+ other frequencies (not in BSS group) summed and sent to RTSP server.



Recording Radio Speech

Recording based on Active sessions opened by VCS or CWP UAs and GRS UA to 2 recording devices (for redundancy);

At instant of PTT/Squelch activation, VCS or CWP UA sends single audio stream (i.e.sum of Rx & Tx audio streams) to Recorder, while

GRS UA sends only Rx Audio stream from incoming A/C call.

Recommended to use RTSP over TCP as reliable delivery service;

Time source used synchronized to UTC to ICAO accuracy.Timestamps sent by VCS/CWP UAs & GRS UA in RTP packets

VCS

Client

User Terminal

Client

Radio

Client

IP NetworkRx Audio OUT

Tx Audio OUT

Rx Audio IN

Tx Audio IN

Recorder

Server

User Tx+Rx Audio

Rx audio only

VCS Tx audio only

VCS Rx audio only

(optional)

(optional)

(Legal)

(optional for

Radio Rx)

Rx+Tx audio

(optional for

Radio Tx/Rx)

ED-137B Volume 4 -Recording Req (4)RTSP session teardown: only after all audio packets arrived .

Sufficient Bandwidth: ensure packet drop does not occur due

to congestion.

RTSP session for G/G comms: 1st G/G call causes RTSP

session to be established. Other concurrent calls at CWP (i.e.

OVR, IA, Intrusion, DA call), keep the same RTSP session.

Audio from all parties summed and sent to RTSP server. RTSP

session terminated when last call ends.

RTSP session for A/G comms: RTSP session established

when the 1st frequency configured at CWP. With addition of

further frequencies, the same RTSP session is used. Summed

audio from all frequencies sent to RTSP server. RTSP session

cleared when last frequency unconfigured.

Rx voting: Audio from voted receiver+ other frequencies (not in

BSS group) summed and sent to RTSP server.


ED-137B Volume 4 -Recording Req (5) Main/Standby Radios: Both Main and Standby radios SHOULD establish a single RTSP session with the

RTSP server. Dual sessions MAY be established.

TCP Keepalive mechanism: ensures connectivity between Client and RTSP server;

Loss of RTSP session SHOULD cause procedures for its immediate re-establishment to be started.

RTSP server limit: RTSP server SHALL have capability of handling multiple sessions simultaneously.

CWP client SHALL have capability of handling multiple RTSP sessions at least 1 session for G/G calls and 1

for A/G calls.

G/G comms referenced by: RTSP session id, Connref, callref, ThreadRef

A/G comms referenced by: RTSP session id, Connref, ThreadRef




Main/Standby Radios: SHOULD establish single RTSP session with RTSP server. Dual sessions MAY be established.

TCP Keepalive mechanism: ensures connectivity between Client and RTSP server;

Loss of RTSP session: SHOULD initiate procedures for its immediate re-establishment.

RTSP server limit: SHALL be capable of handling multiple sessions simultaneously.

CWP client SHALL have capability of handling multiple RTSP sessions at least 1 session for G/G calls and 1 for A/G calls.

G/G comms referenced by: RTSP session id, Connref, callref, ThreadRef

A/G comms referenced by: RTSP session id, Connref, ThreadRef


Methodology for Voice recording

RTSP session signaling procedures between clients and RTSP server

1. The client is enabled to request establishment of an RTSP session to a RTSP server that has an RTSP address defined in its permissions list (if enabled);

2. The RTSP server is enabled to accept an establishment request for an RTSP session from a User Terminal, VCS or Radio client that has an RTSP address defined in its permissions list (if enabled);

3. For G/G communications a client is triggered to establish an RTSP session with its nominated RTSP server on outgoing G/G call initiation (i.e. sending SIP INVITE) or on incoming G/G call receipt (i.e. receiving a

SIP INVITE);

4. For G/G communications one RTSP session SHALL therefore be established per incoming or outgoing telephone call by each User Terminal or VCS client to its nominated RTSP server.

5. Assuming that each User Terminal or VCS client will have its own nominated RTSP server (Recorder equipment), a G/G communication between clients would result in both having its own independent RTSP

session with a RTSP server (recorder equipment).

6. For A/G communications a client is triggered to establish an RTSP session with its nominated RTSP server on SIP radio session initiation towards a radio (i.e. sending a SIP INVITE) or on receipt of a SIP radio

session request from a VCS (i.e. receiving a SIP INVITE);

7. To initiate RTSP session establishment the client sends an RTSP ANNOUNCE message to the RTSP server.

8. An ANNOUNCE control message containing an SDP message body with a valid media description and rtpmap attribute appropriate for the audio codec G.711 PCM A-law or mu-law SHOULD therefore always

be offered by the User Terminal, VCS or Radio client to the RTSP server.

9. When receiving an RTSP ANNOUNCE message from the User Terminal, VCS or Radio client, the RTSP server SHOULD verify that the RTSP address matches its own address. In the case that they are different

the RTSP server can reject the message through a 404 Not found response.

10. When receiving an RTSP ANNOUNCE message, the RTSP server SHOULD also verify that it can accept the media description and rtpmap attribute in the SDP message body.

11. In the case that the media description and rtpmap attribute being offered by the User Terminal, VCS or Radio client is not supported by the RTSP server, it SHOULD reject the ANNOUNCE message with a

415 Unsupported Media type response code by a 488 Not acceptable here response or by a 606 Not Acceptable response.

12. On receipt of a 4xx failure response to , the client SHALL indicate RTSP session failure.

13. In the case that the media description and rtpmap attribute being offered by the User Terminal, VCS or Radio client is supported by the RTSP server, a 200 OK success response to the ANNOUNCE message

SHOULD NOT contain an SDP message body.

14. On receipt of 200 OK successful response the client sends an RTSP SETUP message to the RTSP server.

15. When receiving an RTSP SETUP message from the VCS or Radio client, the RTSP server SHOULD verify that the RTSP address matches its own address. In the case that they are different the RTSP server

can reject the message through a 404 Not found response.

16. On receipt of a 4xx failure response, the client SHALL indicate RTSP session failure.

17. On receipt of 200 OK successful response the RTSP session has been successfully established.



18. The RTSP server (Recorder equipment) will generate a session identifier in response to a SETUP request. A session identifier is chosen randomly by the RTSP server and is at least eight octets long to make guessing

it more difficult. The RTSP server will assign a Session identifier in its 200 OK response to the SETUP

message from the VCS or Radio client.

19. On RTSP session timing out, the User Terminal, VCS or Radio client SHOULD attempt to re-establish the RTSP session towards the RTSP server.

20. Once an RTSP session has been opened between User Terminal, VCS or Radio client and RTSP Server (i.e. recorder equipment), the RTSP Server SHOULD keep the session permanently open until instructed to tear

down the session by the User Terminal, VCS or Radio client. The RTSP server SHOULD NOT therefore

close the session due to internal inactivity timeouts.

21. For G/G communications a client is triggered to teardown an established RTSP session with its nominated RTSP server when a G/G communication is cleared by either party (i.e. on sending or receiving a BYE

request) or in the case of call intrusion or conference, when the last call is cleared.

22. For A/G communications a User Terminal client is triggered to teardown an established RTSP session with its nominated RTSP server when the last frequency is unassigned at the position. In most cases the RTSP

session in the case of radio can be considered to be permanent due to a position always have at least one

(emergency frequency) assigned.

23. For A/G communications a VCS client is triggered to teardown an established RTSP session with its nominated RTSP server when the SIP radio sessions to the radio frequency it is recording has been

terminated. At the VCS client there could be one RTSP session established for each radio frequency.

24. For A/G communications a Radio client is triggered to teardown an established RTSP session with its nominated RTSP server when the SIP radio session to the VCS has been terminated.

Methodology for Voice recordingUA_A1 at

VCS/GRS EndpointUA_B1 at

Recorder endpoint

INVITE (F1) SDP defines RTSP Rec application + Port numbers

200OK (F6)

SIP session

establishment 200OK (F2)

ACK (F3)

ANNOUNCE (RTSP control mesage) SDP defines media as G.711 A-law

200OK (F4)

SETUP (RTSP control mesage) SDP defines Transport RTP/AVP/TCP

and Embedded Interleaved Binary data (F5)

RECORD (RTSP control message) (F7)

200OK (F8)

PAUSE (RTSP control message) (F9)

200OK (F10)

RECORD (RTSP control message) (F11)

200OK (F12)

SET PARAMETER (RTSP control message) (F13)

200OK (F14)

TEARDOWN (RTSP control message) (F15)

200OK (F16)

RTSP session

establishment

Media Transport

Method: Embedded

(Interleved) Binary Data

Start Audio

transmission

Pause Audio

transmission

Start Audio

transmission

again

Send Calll

Record Data

RTSP session

termination


Replay functionality

REPLAY (optional)

Can optionally implement the REPLAY functionality accepting the DESCRIBE and PLAY RTSP

control messages used to identify a stored session and play it back for 3rd parties to hear;

The message sequence in the slide SHOULD be used to identify the audio message to be played, at a replay

client, setup the ports and media transport method for the audio transfer, send the stored audio message (Play),

pause the message (Pause) and finally teardown the session. It is comprised of DESCRIBE, SETUP, PLAY,

PAUSE and TEARDOWN messages.

DESCRIBE rtsp://recorder:554/replay/?connref=403C232A-C510-45C7-973E-D55F5CF996AF RTSP/1.0

CSeq: 2

Accept: application/sdp

RTSP/1.0 200 OK

CSeq: 2

Server: Example Recorder

Content-Type: application/sdp

Content-Length: 157

v=0

o=unnamed 0 0 IN IP4 playback.example.net

s=Example Stream

t=0 0

a=range:npt=0.0-9.420000000

a=length:npt=9.420000000

m=audio 0 RTP/AVP 8

a=rtpmap:8 PCMA/8000

SETUP rtsp://recorder:554/replay/?connref=403C232A-C510-45C7-973E-D55F5CF996AF RTSP/1.0

CSeq: 3

Transport: RTP/AVP/TCP;unicast;mode=PLAY;dest_addr=":9";setup=active;connection=new

RTSP/1.0 200 OK

CSeq: 3

Session: 2da07059-961e-4998-81f8-0f6345e0b15f


Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";src_addr="192.0.2.5:9000";setup=passive

connection=new;ssrc=93CB001E

PLAY rtsp://recorder:554/replay/?connref=403C232A-C510-45C7-973E-D55F5CF996AF RTSP/1.0

CSeq: 4


Range: npt=0-9.419000

RTSP/1.0 200 Success

CSeq: 4



Range: npt=0-9.419

RTP-Info:url=rtsp://recorder:554/replay/?connref=403C232A-C510-45C7-973E-

D55F5CF996AF;rtptime=3188274789;seq=4082

PAUSE rtsp://recorder:554/replay/?connref=403C232A-C510-45C7-973E-D55F5CF996AF RTSP/1.0

CSeq: 5




RTSP/1.0 200 Success

CSeq: 5



TEARDOWN rtsp://recorder:554/replay/?connref=403C232A-C510-45C7-973E-D55F5CF996AF

RTSP/1.0

CSeq: 6


RTSP/1.0 200 OK

CSeq: 4

Session: c408358f-a233-4dd2-9fb6-a338953cc8b2

Replay functionality

RTSP Server can optionally implement

the REPLAY

functionality,

accepting the

DESCRIBE and PLAY RTSP control messages from a

Replay client.

DESCRIBE used to identify a stored

session.

PLAY used to play it back for 3rd parties to

hear


Call detail records

CALL RECORD DATA format

The following XML structure SHALL be used to transmit call record data within a SET_PARAMETER

message:

value

value

Call Record data SHALL be composed of properties and operations. Any timestamp SHOULD be set by the

client since it has the exact time reference for any local event. If a timestamp value is omitted, the server

SHALL use the message arrival timestamp.

Properties

Properties are single values that will not change during the lifetime of a connection and usually do not require a

time reference, except for properties that are representing timestamp information.

A client MAY send an updated value of a property that is already set if the new value is a more accurate one. In

that case the recorder MAY overwrite the previous value if present. The recorder does not need to hold any

previous values since properties are only those values that can have only one instance for a connection. For

example, the direction of the connection never changes during its lifetime.

Examples:

Direction (of the connection): 0 = unknown (default), 1 = incoming, 2 = outgoing

1

Priority: 1 emergency, 2 urgent, 3 normal, 4 non-urgent3

CallingNr, CalledNr, AlertingNr, ConnectedNr: preferred in "tel:" URI format

tel:+4311503

SetupTime, AlertTime, ConnectTime, DisconnectTime: utc-datetime

2007-08-01_05-50-00.789+0000

DisconnectCause: Cause values according to ITU-T Rec. Q.931

19

DisconnectSource: 0 = unknown (default), 1 = calling side, 2 = called side, 3 =other

1

Call Type: Classification of call type, 1 = DA call, 2 = IA call, 3 = OVR call

1

CallRef: a common CRD identifier between calling and called party for one telephone call

[email protected]

ThreadRef: a common Thread Reference identifier between calling and called party for one telephone call or

SIP Radio session. Value remains the same during a call transfer.

[email protected]

PTTid: PTT=id value assigned by Radio to VCS client when establishing SIP session

000001



Operations

Operations are events during the lifetime of a connection that may happen at any time and SHOULD be

preserved at the recorder. Examples:

RedirectedNr: Representing a "tel:" URI format to notify a redirection with the new target.

+431156

TransferredNr: Representing a "tel:" URI format to notify a change in the Contact address header with the

conference URI.

+431156

HOLD indicate when a call is put on hold- 0=call not on-hold, 1=call put on-hold by calling party, 2=call put

on-hold by called party.

2

PTT: change of PTT state

0

SQU: change of SQU state

0

PTTS: change of PTTS state

1

PM: change of PM state

1

VOTING indicate selected Rx by voting algorithm

1

Telephone Call Record Data Properties

User Terminals (T) SHALL and VCS network interfaces (V) SHOULD transmit the following properties to the

Recorder using SET_PARAMETER.

Call detail records

SET_PARAMETER RTSP control message used to transmit call record data to Recorder- consists of Properties & Operations:

Timestamps set by Client as it has exact time reference for any local event;

Properties: single values that dont change and often have no time source associated. Updated if more accurate values ready.

In this case Recorder can overwrite previous values.

Properties values include: Direction, Priority, CallingNr, CalledNr, AlertingNr, ConnectedNr, SetupTime, AlertTime, ConnectTime,

DisconnectTime, ReleaseTime, DisconnectCause,

DisconnectSource, Type of data (Speech)

Operations: events that occur during lifetime of call: RedirectNr, CallRef, ThreadRef, PTT-State (ON/OFF) etc


LIST OF TELEPHONE PROPERTIES

Property Format Description/Example Source Requirement

Direction INTEGER 0...unknown,

1...incoming,

2...outgoing

T or V mandatory

Priority INTEGER 1 - emergency

2 - urgent

3 - normal

4 - non-urgent

T or V mandatory

CallingNr TEL URI tel:+4311503

T or V mandatory

CalledNr TEL URI tel:+4311503 T or V mandatory

AlertingNr TEL URI tel:+4311503

T or V optional

ConnectedNr TEL URI tel:+4311503 T or V optional

SetupTime UTC

DATETIME

2007-08-01_05:40:30.123+0000

T or V mandatory

AlertTime UTC

DATETIME

2007-08-01_05:40:30.123+0000

T or V optional

ConnectTime UTC

DATETIME

2007-08-01_05:40:30.123+0000

T or V optional

DisconnectTime UTC

DATETIME

2007-08-01_05:40:30.123+0000

T or V mandatory

DisconnectCause INTEGER As defined by ITU-T Rec. Q.931

T or V optional

DisconnectSource INTEGER 0Unknown 1...calling side,

2...called side

3other

T or V mandatory

Call Type INTEGER 1...DA call

2IA call 3OVR call

T or V optional

CallRef STRING 583a74a2-0c8b3964-020acf0e-

[email protected]

T or V optional

ThreadRef STRING 692b89d1-1b123981-134af0d1-

[email protected]

T or V optional

ConfRef STRING 784cd851-6f65416-543af0e1-

[email protected]

T or V optional

CALL TIMER PROPERTIES AND MEANING

Timer property Meaning

SetupTime Calling client: time when a SIP INVITE request is sent.

Called client: time when a SIP INVITE request is received.

AlertTime Calling client: time when a 180Ringing response is received.

Called client: time when a 180Ringing response is sent.

ConnectTime Calling client: time when a 200 OK response is received.

Called client: time when an ACK to the previously sent 200 OK response is

received

DisconnectTime Clearing client : time when a SIP BYE request is sent for an established point-to-

point communication.

Cleared client: time when a SIP BYE request is received for an established point-

to-point communication.

Clearing conference: time when the last SIP BYE request is sent in a conference

(when last two users remain)

Call Reject: time of the 4xx/5xx/6xx response.

.



Telephone Call Record Data Operations

User Terminals (T) SHALL transmit the following operations to the Recorder using SET_PARAMETER. Note:

Operations include per definition a UTC date-time reference as unique timestamp.

LIST OF TELEPHONE OPERATIONS

Operation Format Description/Example Source Requirement

RedirectedNr TEL URI tel:+4311503 T mandatory

TransferredNr TEL URI tel:+3411503 T optional

HOLD INTEGER

0 = 0 - hold off, call is not on hold

- 1 1 - call has been put on hold by

calling party

2 - call has been put on hold

by called party

T optional

Radio Call Record Data Properties

User Terminals (T) SHALL and VCS Network interfaces (V), Radios (R) and Radio Remote Control

Equipment (RRC) SHOULD transmit the following properties to the RTSP server (Recorder) using

SET_PARAMETER.

LIST OF RADIO PROPERTIES

Property Format Description/Example Source Requirement

FrequencyID STRING 118.005 T,V,R,RRC mandatory

PTTid INTEGER 000000.111111 T,V,R,RRC mandatory

BSS Method INTEGER 0...7 R,RRC optional

CallingNr TEL URI tel:+4311503 T,V,R,RRC optional

CalledNr TEL URI tel:+4311502 T,V,R,RRC optional

Direction INTEGER

0...unknown

1...incoming

2...outgoing

T,V,R,RRC optional

Radio Call Record Data Operations

User Terminals (T) SHALL and VCS network interfaces (V), Radio (R) and Radio Remote Control Equipment

(RRC) SHOULD transmit the following operations to the Recorder using SET_PARAMETER. Note:

Operations include per definition a UTC date-time reference as unique timestamp.

LIST OF RADIO OPERATIONS (1)


PTT INTEGER

0 - PTT OFF

1 - Normal PTT ON

2 - Coupling PTT ON

3 - Priority PTT ON

4 - Emergency PTT ON

T,V mandatory

SQU INTEGER 0 - OFF

1 - ON R, RRC

mandatory for Radio and

RRCE in single

frequency mode

PTTS INTEGER 0 - OFF

1 ON T,V,R,RRC mandatory

PM INTEGER 0 - OFF

1 - ON T,V,R mandatory

Simultaneous

Transmission INTEGER

0 - None detected

1 - Simultaneous transmission

detected

R

mandatory

BSS Quality

Index INTEGER -100...-70 (RSSI) R,RRC

optional (also used in

RRC single frequency

mode)

VOTING INTEGER 0 - voting disabled, default option

1 - voting enabled, current SQU T optional



connref selected by voting

algorithm

2 - voting enabled, current SQU

connref not selected by voting

algorithm

In addition the following operations relating to Radio Remote Control Equipment (RRCE) configured in Paired

frequency mode only SHOULD be included:



SQF1 INTEGER

0 - OFF

1 - ON

RRCE

mandatory (RRCE

paired frequency

mode)

SQF2 INTEGER

0 - OFF

1 - ON

RRCE

mandatory (RRCE

paired frequency

mode)

BSS Quality

Index

SQI F1

INTEGER -100...-70 (RSSI) RRCE optional (RRC paired

frequency mode only)

BSS Quality

Index

SQU F2

INTEGER -100...-70 (RSSI) RRCE optional (RRC paired

frequency mode only)

In the case Radio Remote Control equipment (configured in either single or paired frequency mode) the

following operations SHALL also be included within a SET_PARAMETER message sent to the Recorder each

time a RRC command message is sent or a RRC Response message is received.

A copy of 8 RRC control bits within a RRC Command message sent to Radio Remote Control Equipment (RRCE) in the RTP Tx Header Extension Type 3, expressed as 8 Binary bits.

A copy of the 8 RRC control bits within a RRC Response message received from the Radio Remote Control Equipment (RRCE) in the RTP Rx Header Extension Type 3, expressed as 8 Binary bits.



RRCC INTEGER

Bit 12345678

00000000 - 11111111

RRCE

mandatory (RRCE in

single and paired

frequency mode)

RRCR INTEGER

Bit 12345678

00000000 - 11111111

RRCE

mandatory (RRCE in

single and paired

frequency mode)



This page is intentionally blank.


Basic Outgoing Call- Answered Example Rules Telephone Call Record Data

Call Record Data relating to telephone calls SHOULD be sent at call initiation, call accept/refusal and at call

termination.

The call initiation CRD SHOULD be included in:

SET_PARAMETER message with XML body that follows the initial SETUP message without XML body

The call accept CRD SHOULD be included in either:

RECORD with XML body

SET_PARAMETER with XML body, RECORD SHALL still be sent when call is accepted

The call termination CRD SHOULD be included in either:

PAUSE with XML body followed by a TEARDOWN message without XML body

SET_PARAMETER with XML body, PAUSE and/or TEARDOWN SHALL still be sent when call is terminated

TEARDOWN with XML body without a previous PAUSE message being sent

SETUP without Call Record Data

As the SETUP message may be parsed by external device (ex. firewalls), the implementation of this message

SHALL be strictly compliant with RFC 2326 to avoid any interoperability issue. The SETUP message SHALL

therefore carry only transport information and SHALL NOT include an XML message body containing CRD.

Rules for Radio Call Record Data

Call Record Data (CRD) relating to A/G communications SHALL be sent to the RTSP server:

at SIP Radio session establishment/teardown

each time there is a change in control bits being sent to the Radio or Radio Remote Control Equipment (RRCE) and when there is a change in the status indication bits being received from the Radio or

RRCE.

The SIP radio session initiation CRD SHOULD be included in the initial SETUP message with XML body.

PTT or SQU activation CRD SHOULD be included in:

a RECORD message with XML body

PTT or SQU deactivation CRD SHOULD be included in:

a PAUSE message with XML body

Change in control bits at any time (i.e. PTTS, PM, SCT or RRC Control bits etc)

a SET_PARAMETER message with XML body

The SIP radio session termination CRD SHOULD be included in either:

PAUSE with XML body followed by a TEARDOWN message without XML body

SET_PARAMETER with XML body, PAUSE and/or TEARDOWN SHALL still be sent when call is terminated

TEARDOWN with XML body without a previous PAUSE message being sent



Basic Outgoing Call- Answered

Example

SET_PARAMETER (sent after 200 OK response received to RTSP SETUP)

[email protected]

2

1

tel:1111

tel:2222

2011-05-16_08:30:30.123+0000

RECORD (sent when call answered on receiving 200 OK response to sent SIP INVITE)

tel:2222

2011-05-16_08:30:36.123+0000

TEARDOWN (sent when call cleared on sending or receiving SIP BYE)

2011-05-16_08:30:50.123+0000

16

1

Following assumes that SETUP message has already been sent to establish

session with RTSP server. The following messages are then sent:


VCS-GRS-Recorder Interoperability Test Configuration

VCS-GRS-Recorder -Active Recording Tests over WAN

This section defines a series of Active Recording tests with the purpose of verifying that a Recording Equipment

is able to record both Voice Media and Call Record Data relating to calls made between:

SIP Telephone User Agent to SIP Telephone User Agent

SIP Radio User Agent (VCS side) to SIP Radio User Agent (Radio Side)

SIP Radio User Agent (Radio side) to SIP Radio User Agent (VCS side) and also the audio exchanged during the

Active Recording implies that SIP User Agents that receive and/or send media streams, also send a copy of that

media stream to an independent SIP User Agent Recording equipment.

Any SIP Telephone User Agent with a voice communication establishment should therefore combine its

incoming and outgoing audio streams into a single audio stream towards the Recording equipment. The SIP

Telephone Users Agents are also responsible for opening a session with the Recording Equipment prior to the

delivery of an audio stream.

Any SIP Radio User Agent (VCS side) with a voice communication establishment should therefore combine its

incoming and outgoing audio streams into a single audio stream towards the Recording equipment. The SIP

Radio Users Agents (VCS side) are also responsible for opening a session with the Recording Equipment prior

to the delivery of an audio stream.

Any SIP Radio User Agent (Radio side) with a voice communication establishment should send only its

incoming audio stream towards the Recording equipment. The SIP Radio Users Agents (Radio side) are also

responsible for opening a session with the Recording Equipment prior to the delivery of an audio stream.

It is assumed that Recording Equipment shall be able to record multiple audio streams simultaneously and that

one or many Recording Equipment units may be present in a domain.

In the case of a requirement to have the audio streams recorded by two independent Recording devices within

an operational environment, then it will be necessary to also have redundant recording equipment present in

order that a User Agent can open sessions with both simultaneously and send the same audio stream to both.

It is also assumed that both Telephone and Recording SIP user agents have previously registered themselves

with a SIP REGISTRAR sever within the domain in which they are operating.

High Level description of the VCS/Radio Recorder interoperability tests

IDENTIFIER DESCRIPTION

LAN-REC1 Direct Access Routine call Voice media and Call Record Data recording test scenario

LAN-REC2 Direct Access Priority call Voice media and Call Record Data recording test scenario

LAN-REC3 Instantaneous Access call Voice Media and Call Record Data recording test scenario

LAN-REC4 Outgoing Radio call Voice media and Call Record Data recording test scenario

LAN-REC5 Incoming Radio call Voice media and Call Record Data recording test scenario

LAN-REC6 DA, IA or Radio Call voice media replay test at replay client test scenario (optional)

LAN-REC7 SIP-Ping test between A1 (VCS side) and the SIP Recorder D1 in order to check for link

connection loss or SIP Recorder failure

LAN-REC8 SIP-Ping test between C1 (Radio side) and the SIP Recorder D1 in order to check for link

connection loss or SIP Recorder failure

LAN-REC9 Direct Access Priority Call Intrusion Voice media and Call Record Data recording test



VCS-GRS-Recorder Interoperability

Test Configuration

VCS1

CWP 1,2,3..n

UA_A1

Sub-network 1

Wire

shark

UA_A1

UA_B1

VCS2UA_B1

CWP 1,2,3..n

Sub-network 2

Wire

shark

Sub-network 4

Recorder

UA_D

1

Wire

shark

UA_C1

Radio Transceiver

Sub-network 3

Wire

shark



- Part 3

Network performance aspects


3. Network performance aspects


Call performance criteria for DA and IA

o Direct Access is designed to meet the requirements for Direct Controller-Controller Voice Communication (DCCVC) which stipulates that communication be established between controllers within 2 seconds in

99% of the time

o The interval of 2 seconds is the delay between the 'A'-party initiating the call and the 'B'-party receiving the call alert/indication.

It is known however that in case of ATS-R2 and ATS-No.5 analogue signalling protocols, this establishment time

is not achievable.

o Instantaneous Access is designed to meet the requirements of Instantaneous Controller-Controller Voice Communication (ICCVC) which stipulates that two-way direct communication be established between non-

physically adjacent controllers within 1 second or less in 99% of the time.

o The interval of 1 second is the delay between the 'A'-party initiating the call and the 'A'-party to 'B'-party speech path being established.



Call performance criteria for

DA and IA ICAO Doc 9804 AN/762 Manual on ATS G/G Voice switching &

signalling doc states:

Direct Access is designed to meet requirements for Direct Controller-Controller Voice Communication (DCCVC): communication to be

established between controllers within 2 seconds in 99% of the time;

The interval of 2 secs is delay between 'A'-party initiating call and

'B'-party receiving call alert/indication.

Instantaneous Access is designed to meet requirements of Instantaneous Controller-Controller Voice Communication (ICCVC)

which stipulates that 2-way direct communication be established

between non-physically adjacent controllers within 1 second or less in

99% of the time.

The interval of 1 second is the delay between 'A'-party initiating call

and 'A'-party to 'B'-party speech path being established.


One way Voice Delay for Telephone

Voice Delay is the time it takes a voice signal to travel end-to-end between talker and listener and the effect is

the apparent lag between the end of the talkers sentence and the start of the listeners response. If this time is relatively too long compared to the standard human speech, the discussion can be perceived with hesitations. The human brain has to judge not only the voice but also the timing of the dialogue between the two participants

which can lead to the unexpected situation where the conversation can be difficult to pursue, reaching a

communication break-down for very high and unnatural delay. The delay latency is based on the physical

propagation of the signal on the transmission path.

The use of voice coding methods introduces extra delays in the speech path due to the large number of speech

samples required to process the speech signal correctly. Typical one-way delay contributions from speech

encoding are defined in the table below:

Voice Codec Voice Bandwidth Processing Delay (ms)

G.711 PCM A-law, -law 64kbps 0.75

G.728 LD-CELP 16kbps 3-5

G.729 CS-ACELP 8kbps 15

Further delays are introduced by processing at the terminating VCSs and at any transit VCSs etc.

As defined by ITU-T Rec. G.114, the voice delay between endpoints over a network should not exceed 200ms.

Voice communication over Geostationary satellites has latency delays in excess of 260ms (or 350ms with the

Ground segment included) and for this reason are recommended only for use as emergency backup facilities.

Voice delays in excess of 400ms are generally unacceptable.

The EUROCAE WG67 have a requirement that states that the one-way voice delay for ground-ground

communication between CWPs located within the same or different ATSUs SHALL be less than 150 ms, in compliance with ITU-T recommendation G.114 (05/03).

NOTE: ITU-T G.114 (05/03) Appendix II Guidance on one-way delay for Voice over IP states that for many intra-regional routes (e.g., within Africa, Europe, North America) within the range of 5000 km or less, users of

VoIP connections are likely to experience mouth-to-ear delays



One way Voice Delay for Telephone

ED136: The one-way voice delay for ground-ground

communication between CWPs located within the same or

different ATS units SHALL be less than 150 ms, in

compliance with ITU-T recommendation G.114 (05/03)

ITU-T G.114 (05/03) Appendix II Guidance on one-way delay for Voice over IP states that for many intra-regional routes (e.g., within Africa, Europe, North America) within the range of

5000 km or less, users of VoIP connections are likely to experience mouth-to-ear delays


One way Voice Delay for Radio

The system SHALL comply with the RADIO SYSTEM PERFORMANCE REQUIREMENTS of 130ms max

Ground Transmission Voice delay.

The transmission time for connections with digital segments is comprised 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.

Due to specific requirements applicable to radio, the voice latency for ground transmission components within

the ATS Ground Voice Network SHALL have a maximum one-way delay of 130ms.

As an example the contribution made by each element in both the transmit and receive paths to the overall end-

to-end voice latency is defined in the slide. The values defined have been based on the use of the ITU-T G.711

Codec and the employment of a 20ms packet size:

The encoding side of the Transmit path includes the following elements:

VCS and Local Radio Control Equipment: internal audio to IP output

The decoding side of the Transmit path includes the following elements:

Remote Radio Control Equipment and GRS Transmitter: IP input to antenna modulated signal

The encoding side of the Receive path includes the following elements:

GRS Receiver and Remote Radio Control Equipment: demodulated signal to IP output

The decoding side of the Receive path includes the following elements:

Local Radio Control Equipment and VCS: IP input to internal audio output.



One way Voice Delay for Radio

130MS MAX GROUND TRANSMISSION VOICE DELAY

The voice delay for ground transmission components SHALL be a maximum of 130ms.

Given: Voice delay in the ground transmitter is 10ms and this is included in the 130ms.


Voice Quality of A/G & G/G communications

Speech Quality and Intelligibility

To compare the performance of two speech codecs, it is necessary to have some indicator of the intelligibility

and quality of the speech produced by each codec. The term intelligibility usually refers to whether the output

speech is easily understandable, while the term quality is an indicator of how natural the speech sounds. It is

possible for a coder to produce highly intelligible speech that is low quality in that the speech may sound very

machine-like and the speaker is not identifiable. On the other hand, it is unlikely that unintelligible speech

would be called high quality, but there are situations in which perceptually pleasing speech does not have high

intelligibility. This section examines the most common measures of intelligibility and quality used in formal

tests of speech codecs. Some newer performance indicators that attempt to incorporate the effects of the network

on speech coder performance in particular applications are highlighted.

Mean Opinion Score (MOS)

The Mean Opinion Score (MOS) is an often-used performance measure. To establish a MOS for a codec,

listeners are asked to classify the quality of the encoded speech in one of five categories: excellent (5), good (4),

fair (3), poor (2), or bad (1). The numbers in parentheses are used to assign a numerical value to the subjective

evaluations, and the numerical ratings of all listeners are averaged to produce a MOS for the coder. A MOS

score of 4.0 is usually considered Toll quality, meaning its the quality associated with the traditional PSTN service.

A MOS between 4.0 and 4.5 usually indicates high quality.

MOS Rat ing indica t ions

Rating Speech Quality Distortion Level

5 Excellent Imperceptible

4 Good Just perceptible, not annoying

3 Fair Perceptible, slightly annoying

2 Poor Annoying, but not objectionable

1 Unsatisfactory Very Annoying, Objectionable

It is important to compute the variance of MOS values. A large variance, which indicates an unreliable test, can

occur because participants do not know what categories such as good and bad imply. It is sometimes useful to

present examples of good and bad speech to the listeners before the test to calibrate the 5-point scale. Sometimes

the percentage of poor and bad votes may be used to predict the number of user complaints. MOS values can

and will vary from test to test and so it is important not to put too much emphasis on particular numbers when

comparing MOS values across different tests.

Perceptual Evaluation of Speech Quality- Listening Quality Objective (PESQ-LQO)

PESQ MOS-LQO provides an objective measurement that predicts the results of subjective listening tests on

telephony systems. To measure speech quality, PESQ uses a sensory model to compare the original,

unprocessed signal with the degraded version at the output of the communications system (see Figure below).

The result of comparing the reference and degraded signals is a quality score. PESQ is a more common method

and would have results recorded with a MOS-LQO score. Providing PESQ MOS-LQO is used, this score is

analogous to the subjective Mean Opinion Score (MOS) measured using panel tests according to ITU-T P.800.

The PESQ MOS-LQO as defined by the ITU recommendation P.862.1 ranges from a score of 1.0 (worst) up to

4.5 (best). This may be surprising at first glance since the ITU P.800 MOS score has a range from 0 to 5.0, but

the explanation is simple: PESQ simulates a listening test and is optimized to reproduce the average result of all

listeners (remember, MOS stands for Mean Opinion Score). Statistics however prove that the best average result

one can generally expect from a subjective listening test is not 5.0, instead it is ca. 4.5. It appears the subjects

are always cautious to score a 5, meaning "excellent", even if there is no degradation at all.



Voice Quality method to obtain PESQ MOS-LQO score

The E-Model

Another relatively recent objective method for speech quality evaluation is the E-Model in ITU

Recommendation G.107 and G.108. The E-Model attempts to assess the "mouth to ear" quality of a telephone

connection and is intended to be used in network planning. The E-Model has components for representing the

effects of "equipment" and different types of impairments. The equipment effects include a term representing

the "intrinsic" quality of the codec and a term due to the effects of packet loss concealment. There is also a term

to model the loss in quality caused by delay. All of the components are summed to produce an R-value on a

psychoacoustic scale, which maps to user satisfaction as shown in the Figure below. Guidelines are given for

mapping the R-values into MOS values as shown in the following Table below. Some studies caution that the E-

model may not sufficiently distinguish between various combinations of codec impairments and delay that are

clearly perceived differently by users.

Voice Quality of A/G & G/G

communications

R-value

range

Speech

Transmission

Quality Category

User

Satisfaction

MOS

90 R < 100 Best Very Satisfied 4.3

80 R < 90 High Satisfied 4.0

Voice Transmission Quality: system SHALL achieve a Mean Opinion Score (MOS) > 4.0 (Equal to 80 R < 100) for all A/G and G/G communications.

The system SHALL ensure during any call, users own echo is within acceptable area of ITU-T G.131

for both tel. (reflected echo) and

radio (sidetone).


Mapping of the E-model R-Values into MOS

User

Satisfaction

Very

Satisfied

Satisfied Some

Dissatisfied

Many

Dissatisfied

Nearly All

Dissatisfied

Not

Recommended

R 100-90 89-80 79-70 69-60 59-50 Below 50

MOS 4.5-4.3 4.3-4.0 4.0-3.6 3.6-3.1 3.1-2.6 Below 2.6

Effect of One-way Delay on speech Quality (G.114)

The E-Model is a transmission-planning tool for estimating the user satisfaction of a narrowband, handset

conversation, as perceived by the listener. It is not intended for predicting absolute user satisfaction. Instead, the

intent is to model the performance of an unknown connection relative to a connection with known performance.

The E-Model has proven to be versatile tool that has adapted well to the impairments of IP telephony.

The following figure gives some indication between the user satisfaction and the value provided related to the

communication quality.

There is different measurement which are defined in the following figure:

R value, MOS, %GOB, % POW.

Correlation of E-mode R-value to MOS

The R-value is a scalar called the Rating Factor, or simply R.



R gives an indication of the overall quality of the conversation. The scale is typically from 50 to 100, where everything below 50 is clearly unacceptable and everything above 94 is unobtainable in narrowband (300 to

3400 Hz) telephony. The arrow on the left-hand side of the figure illustrates this point.

MOS (Mean Opinion Score), %GoB (percent Good or Better) or %PoW (percent Poor or Worse) scales are the

result of subjective studies. In subjective testing, subjects are requested to classify the perceived quality into

categories (for example, a five point scale that includes the classifications excellent, good, fair, poor and bad). In

each subjective experiment, the MOS scores may differ, even for the same condition, depending on the design

of the experiment, the range of conditions included in the study.


Transmitter Activation Delay - A/C call indication delay

Transmitter Activation Delay

The Transmitter Activation Delay (TAD) SHALL have a maximum value of 100mS.

Given: 20ms maximum for Transmitter Activation Time (TAT) is included within the 100ms (refer to slide).

The maximum PTT delay is set to 80ms.

Aircraft Call Indication Delay

The ED-136 requirement states that the Aircraft Call Indication Delay (ACD) SHALL have a maximum value of 100mS.

The 50ms maximum for Receiver Activation Time (RAT) is included within the 100ms. (refer to slide).

Note however that Aircraft Call Indication Delay (ACD) is defined by ED-136 as being the sum of delays from

GRx2 to GRx6.

The GRx6 component is the delay of the A/C indication device and is expected to have a value between 20ms

and 50ms.

According to ED-136 definitions the correct Aircraft Call Indication Delay (ACD) is therefore between 70ms

and 100ms.

If they include the RAT of 50ms in this sum (i.e. GRx1), then the Aircraft Call Indication Delay (ACD) has a

value between 120ms and 150ms.

This seems more realistic as it is noted that ED-138 document defines the maximum network delay on the

receive path (GRx4) as 50ms.



Transmitter Activation Delay - A/C

call indication delay


Precedence level assignment of voice services

Class of Service CoS and Quality of Service QoS

Classification: IP Network SHALL provide methods of categorizing traffic into different classes, also called

Class of Service (CoS), and applying QoS parameters to those classes. IP Network SHALL be able to reapply

CoS and QoS parameters to the packets sourced by different systems in the network, in order to ensure the

proper functionality.

Prioritisation: IP Network SHALL provide methods of prioritising traffic based on Class of Service in the LAN

area, according to the IEEE 802.1p and IEEE 802.1q standards, based on a common schema among different

participants in the network (ANSPs). IP Network SHALL provide methods of prioritising traffic based on

Class of Service in the Edge and WAN area.

IP Network SHALL support Differentiated Service (Diffserv) (RFC2474/2475) QoS architecture and SHOULD

support the mapping of different service or traffic classes to Differentiated Service Code Point DSCP.

The DSCP mapping SHALL be configurable when using Diffserv.

When there is an unrecognized DSCP, assigned traffic SHALL be treated according to a default Per-hop-

behaviour PHB that is Best effort.

When using Diffserv the DSCP SHALL be set by the six most significant bits of Traffic Class byte in IPv6 header. Traffic Class SHALL be set by the VoIP ATM application.

When using Diffserv the DSCP SHALL be used and encoded for cross border communication as follows (see

following table):

Eight Class Selector Codepoints compatible with IPv4 and IP Precedence (CS0-7)

An Expedited Forwarding (EF) Class

IP packets are forwarded in N independent AF classes, each having M different levels of drop precedence. Therefore, the Codepoints with the classes and drop precedence form a matrix AFij, where

1 i N and 1 j M. Four classes (N=4) are defined with three Drop Precedences (M=3).

Packets in a higher AF Classes SHOULD have a higher transmit priority

Packets with a higher Drop Precedence SHOULD be more likely to be dropped

DSCP value Codepoint DSCP value Codepoint

000000 CS0 (DEFAULT) 011010 AF31

001000 CS1 011100 AF32

001010 AF11 011110 AF33

001100 AF12 100000 CS4

001110 AF13 100010 AF41

010000 CS2 100100 AF42

010010 AF21 100110 AF43

010100 AF22 101000 CS5

010110 AF23 101110 EF

011000 CS3 110000 CS6

111000 CS7

DSCP values

For cross border communication the IP Network SHOULD set the DSCP field of outgoing packets to the values

shown in the slide.



Precedence level assignment of

voice services

Application DSCP value Codepoint

Default (Best Effort) 000000 CS0

Telephone voice

Radio Voice

101110 EF (Highest possible)

Telephone Signalling

Radio Signalling

100010 AF41

Recording Voice 011010 AF31

Telephone and Radio Voice being real time applications will be prioritized differently than non-real time data by infrastructure;

Voice given Expediated Class (EF). Telephone & Radio signalling

also have high class (AF41);

Recommended EF and AF DiffServ codepoints for Voice & Signalling:


Voice packet duration to IP bandwidth

The slide has the scope of explaining the relationship between Voice Packet Duration and the resulting

equivalent IP bandwidth.

The longer the packet duration, the more voice samples it contains and the effects that the IP/UDP/RTP

header overhead has on the equivalent IP bandwidth is reduced. However there comes a moment when

the reduction in bandwidth due to the longer packet length has a diminishing returns.

In the case of a G.711 (PCM) 64kbps uncompressed voice, it can be seen that the best trade-off is a

packet size of 20ms. This contains 160 voice samples and results in an IPv4 bandwidth of 80kbps. Packet

durations of 40ms and longer have negligible effects on reducing the IP bandwidth.

In the case of a G.729A (CS-ACELP) 8kbps compressed voice, it can be seen that the best trade-off is

still a packet size of 20ms. This contains 2 voice samples and results in an IPv4 bandwidth of 24kbps.

Packet durations of 40ms and longer have negligible effects on reducing the IP bandwidth.

Number of Samples=Packet Duration/Sampling rate. In the case of G.711 PCM the sampling rate is

0.125ms, while in the case of G.729A CS-ACELP the sampling rate is 10ms.

The IPv4 Bandwidth = Original bandwidth + Packets per second x 320 Overhead bits. In the case of a