INTERNET DRAFT Z. Markov Transfer of R2 signaling over the Internet This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract A way of sending of telephone interexchange R2 signals over the Internet is presented. Signals are sent as named events. All signals/events are divided in four groups. The label of the group is transferred as payload type, and type of signal inside the group is transferred as an event code. Transfer of signaling packets over the Real-time Transport Protocol (RTP) utilizes sequencing, numbering and timestamping provided by this protocol. Packets used to transfer the long lasting line signals are intensively transferred only after the change. Labelling of start and the end of signal is performed by marker fields in the header and payload. The reliability of transfer can be increased using the well-known methods of redundant transfer. Introduction Real-time Transport Protocol (RTP, [1]) is a protocol often used for fast transfer of user information in Internet (IP). This protocol is used for transfer of user data in multimedia connections, whether over the H.323 [2] protocol suite, or SIP (Session Initiation Protocol), [3]. RTP is considered to be the user level, and UDP (User Datagram Protocol) is used as transport protocol. The real time transport of information is possible using fast transfers (i.e. transfers without error correction). For increase of quality of audio data, multiple sample transfer is used, as explained in [4]. Similar increase in quality is accomplished by triple transfer of telephone signals in FR (Frame Relay), [5]. Z. Markov page 1 Beside the transfer of user data, RTP payload can be used for transfer of signaling that is transferred in-band, such as telephone tones and signals or DTMF (Dual-Tone MultiFrequency) digits, [6]. Two kinds of signaling can be distinguished: the signaling from the end system (IP phone) or IP gateway, and signaling between two network nodes, so-called RTP trunk signaling. The main reason for this special method of transmission of these in-band signals is that they can not be transferred with sufficient accuracy using the low rate codecs. R2 signaling, [7], is often used in both analog and digital circuit switched telephone networks. In this document, a method of transfer of R2 signals between two exchanges using RTP trunk, is suggested. 1. RTP header and RTP payload As it is well known, [1], the standard header of RTP is consisted of various fields packed into the 12 octets. The fields significant for transfer of telephone signals, tones and digits, are payload type, reference number and timestamp. The payload type field can have only one value, because the payload of one RTP packet can be only of one kind. Some values of payload type field are given in Ref. [8]. Let us emphasize that payload type values 96-127 are planned for dynamic assignment. Reference number of RTP packets is used for the detection of packet loss. Timestamp is used for synchronization of payload transferred by RTP. Payload of RTP packet carries user payload. In this case, we are interested in part of payload carrying signaling information. Signaling information can be transferred in two ways: by payload carrying the information about signals as events, Ref. [6], section 3, and payload carrying the signal parameters, Ref. [6], section 4. The formats for transfer of signals in these two ways are shown in Ref. [6], figures 1 and 3, respectively. The RTP payload fields significant for transfer of signal as an event are event, volume, duration and end. The values representing event codes are given in Ref. [6], table 1, (DTMF 0-16), table 2 (modem), table 3 (data and fax, 32-49), table 4 (E.182 line events, 64-89), table 5 (extended line events (96-112) and table 6 (trunk events, 128-173). 2. R2 signaling R2 signaling, [7], is Channel Associated Signaling (CAS) with both the line and the register signals. The register signals can be analog (analog version of R2, R2A) or digital (digital version of R2, R2D). The line part of signaling is performed outside the speech channel (or time slot) by the signal with frequency of 3825Hz (R2A) or using two bits: a and b in the signaling channel of the E1 multiplex signal (R2D). The register part of the R2 signaling is performed in band, using the signals composed of two (out of six possible) frequencies. Signaling is with acknowledgement so we distinguish forward and backward signals. In electrical sense, there are 15 forward, and 15 backward signals. These signals are grouped, according to their meaning, in tables I and II (forward) and tables A and B (backward signals). Signals I-x and II-x (x=1,2,...15) are Z. Markov page 2 electrically the same. So are the signals A-x and B-x (x=1,2,...15), [7], Rec. Q.441. 3. Requirements for transfer of R2 signaling over RTP Let us assume that two exchanges, both using R2 signaling, are connected by the "RTP trunk" in the following chain: originating exchange, originating gateway, RTP trunk, terminating gateway, terminating exchange. What parameters are necessary to transfer from originating gateway to the terminating gateway using the RTP packets, in order to reconstruct the signal in its original shape? The line signals in R2A require the following values to be transferred: * signal beginning time, * signal end time and * signal level. For the signal beginning and signal end times, the resolution of 20ms is sufficient, [7], Rec. Q.412, subsection 2.2.1. For the line R2D signals, it is needed to transfer: * signal beginning time and * signal end time, with the resolution of 2ms, [7], Rec. Q.422, subsection 3.2.2. The register signals require the following values to be transferred: * signal beginning time, * signal end time, * signal level. Except the values of parameters, the identifier of the register R2 signals direction (forward, backward) must also be transmitted. 4. Proposal of RTP packets carrying R2 signals 4.1. Header Following fields of RTP header are significant for transfer of information: payload type, timestamp, and marker bit, M. To transfer R2 signals using RTP packets, it is needed to recognize signaling RTP packet by the header, i.e. payload type for R2 signals. It is convenient to identify payload type for four types RTP packets. Those are packets carrying the signaling: * R2A line, * R2D line, * R2 register forward and * R2 register backward. The signals belonging to each of these four types of signaling can be represented by a number of events. In the first group those are existence (1) or non-existence (0) of signal, in second - the Z. Markov page 3 combinations of a and b bits, in the third and the fourth starts and ends of one of 15 signals. The payload types for these signalings can be designated by the following fixed values: 41, 42, 43, 44 respectively (if the payload satisfies three conditions from Ref. [8], section 3, because these values are available, or by values from the dynamic range (96-127), Table 2, Ref. [8]). It is very important to observe that each signaling has its own payload type designator. The timestamp indicates the start of signal, i.e. event. If the duration of signal is larger than the time represented by one RTP packet, i.e. it is needed to transfer it by more packets, then each one of them has the same timestamp, and the duration is determined by the timestamp offset that is sent within the packet payload. To reduce the connection time, it is necessary to send the packets as soon as possible, so we propose that the RTP packet represent the signal durations of 20 ms. This way, the connection speed will not be smaller than that of Frame Relay. [5]. It is customary that the time unit for timestamping and time offset equals the time between the two samples of user signal. In the transfer of speech and telephone signals the basic time unit is 125 īs. Marker bit is used to designate the start of an event (M=1). If the number of packets 'covers' the same event, in the second and the other packets M=0. 4.2. Payload of signaling RTP packet The payload of signaling RTP packet has the following fields, resembling Ref. [6], section 3.5.: event code (8 bits), end of event (E), volume (6 bits) and duration (16 bits). Event codes for the signals of R2 signaling are shown in the following list: Signaling Payload type Event Event code R2A line 41 Signal existence 0,1 R2D line 42 ab bits combinations 0,1,2,3 R2 reg. forward 43 Signals I,II-1,15 1-15 R2 reg. backward 44 Signals A,B-1,15 1-15 The E bit indicates the end of event (E=1) or its extension (E=0). Together with M bit it determines the boundaries of an event. The difference between relatively short signals ( register signals, order of hundreds of ms) and the signals that could last as long as the telephone connection (line signals, order of second or minute) should be pointed out here. The transfer of line signals all of the time would overload the RTP trunk, so they are transferred ten times every 20 ms after the change. After that packets are transferred very rarely, for example each 5s as in FR, or not transferred at all. The volume represents the negative value of number of decibels. Therefore, the value 001100 represents the value of -12 dBm0. The duration of R2 signals is of no importance because the signaling is with acknowledgement, i.e. the meaning of signals is only important, regardless of their duration. For better reproduction, the duration of signal is represented as a time offset of event duration from the beginning, i.e. timestamp in the header of RTP packet. Z. Markov page 4 5. Examples In the following figures, some signaling RTP packets are shown. It is assumed that the sequence number and the timestamp both have the value of 1 at the beginning of the connection. Timestamp unit is 125 īs. In the Fig. 1, the format of simple RTP packet for transfer of seizure signal beginning at the start of connection with the R2A signaling is shown. It is needed to emphasize that this signal is represented by tone-on idle signaling method, Ref. [7], Q.411. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |1| 41 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source identifier | | 0x5234a8[6] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E|R| volume | duration | | 0 |0|0| 0 | 160 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 1. In Fig. 2, the second packet, carrying the seizure signal (af=0, bf=0) in R2D is shown. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |0| 42 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source identifier | | 0x5234b8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E|R| volume | duration | | 0 |0|0| 0 | 320 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2. Z. Markov page 5 In Fig. 3, the last packet carrying the register R2 forward signal I-7 (digit 7) is shown. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |0| 43 | 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 4000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source identifier | | 0x5234c8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E|R| volume | duration | | 7 |1|0| 12 | 530 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3. In Fig. 4, the first RTP packet carrying the R2 backward signal A-1 (send next digit) is shown. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P|X| CC |M| PT | sequence number | | 2 |0|0| 0 |1| 44 | 29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | | 3840 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source identifier | | 0x5234d8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E|R| volume | duration | | 1 |0|0| 12 | 160 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 4. 6. Conclusion R2 signaling is the most often signaling in existing circuit switched networks. In this document, the method of transfer of this signaling over the Internet, similar to the one used for the transfer of some simple telephone signals is proposed. It turns out that the Real-time Z. Markov page 6 Transport Protocol (RTP) is very suitable for transfer of R2 signaling for its speed and simplicity. It is suggested that R2 signals should be transferred as events because they can be viewed naturally as the events. Signals can be classified into 4 groups (analog, digital, forward, backward), and each group can be transferred as the different payload type. Inside the one payload type the signals can be transferred as the numbers (of events). Beside the type of events the following elements are also transferred: beginning and the end of signal, volume, and the duration. The time resolution of RTP satisfies the required resolution for transfer of R2 signals. The part of parameters is transferred in RTP header, and the rest is transferred in RTP payload. The redundant transfer for the increase of reliability of signal transfer can be performed in two ways: multiple transfer the same way as in Ref. [6], Section 3.7, or the simultaneous transfer of event designator and signal parameters as in [6], section 5. References [1] Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V.: RTP: A Transport Protocol for Real - Time Application, RFC 1889, 1996 [2] ITU - T: Recommendation H.323: Packet based multimedia communications systems, February 1998 [3] Handley, M., Schulzrinne, H., Schooler, E. and Rosenberg, J.: SIP: Sesion Initiation Protocol, RFC 2543, March 1999 [4] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J. C., Vega-Garcia, A., Fosse-Parisis, S.: RTP Payload for Redundant Audio Data, RFC 2198, September 1997 [5] FRF.11.1: Voice over Frame Relay Implementation Agreement, Frame Relay Forum Technical Committee, December, 1998 [6] Schulzrinne, H. and Petrack, S.: RTP Payload for DTMF Digits, Telephone Tones and Telephony Signals, RFC 2833, May 2000 [7] ITU - T: Recommendations Q4XX: Signaling System R2, November 1988 [8] Schulzrinne, H.: RTP Profile for Audio and Video Conferences with Minimal Control, RFC 1890, January 1996 Author's Address Zarko Markov Iritel 11080 Zemun Batajnicki put 23 Yugoslavia Email: zmarkov@iritel.bg.ac.yu Z. Markov page 7