Subject: Re: avt-tones draft additional transitional signalling message.

From: Marty Borden <[email-masked]>
Date: Fri, 20 Aug 1999 14:23:39 -0400

Mike

I agree that it would be good to carry the ABCD bits as 
a message in the tones draft.  

There definitely is a need to carry the CAS (Channel Associated
Signalling), or ABCD, information.  As you point out, the
interpretation of the bits is somewhat dependent on context or
location.  So I agree with you that it is best to transfer them
transparently.  

Another reason why this is good is for interworking with other
subnetworks.  The Frame Relay Forum carries these as ABCD bits.
The ATM Forum voice trunking over ATM work group  is also discussing
this.  It would be good to carry them transparently and not treat
them as a named message, to be reinterpreted as ABCD at an 
interworking function.

The encoding you suggest is fine with me.

The redundancy and timing needs a little more thought.  I conjecture
that the FRF based some of its considerations on the work done
in the ITU.  However FRF.11 deals with redundancy in a different
manner.  They send a current sample along with 2 previous samples
(in brief) in each packet.  

However the original ITU document, ITU 366-2, Annex L provides a
redundancy mechanism much more like RFC 2198 and the tones draft.  The
method used there is triple redundancy.  At the time of a transition,
the same ABCD information is sent 3 times at an interval of 5 msec
each.  If another transition occurs during this time, then this
continues (subject to debouncing which is not specified nor
precluded).  After a period of no change, the ABCD information is sent
every 5 sec.

I like this latter approach better than the one from FRF.11 for this application.

marty

At 08:26 PM 08/18/99 , Fox, Mike wrote:
>I would like to suggest an additional message for the avt-tones draft. The
>intent of the message is to convey the transitional signalling events (ABCD
>bits) associated with a channel or DS0. 
>
>The FRF.11 Annex B provides a Signalling Bit Transfer Syntax where
>transitional signaling is indicated every 20ms for the 500ms after
>transition, and at 5 second intervals. The transmitter may debounce the bit
>values prior to transmission but this is not required.
>
>As background, the T1 ESF (extended super frame format ) allows 2, 4, and 16
>state signalling bit options. These signalling bits are named A, B, C, and
>D. Signalling information is sent on frame 6,12,18, and 24 on a ESF T1. A D4
>superframe only transmits 4 state signalling with A and B bits. On the
>European E1 CEPT frame, all signalling is carried in timeslot 16, and 2
>channels of 16 state (ABCD) signalling are sent per frame.
>
>In the avt-tones draft, many of the indications on-hook, off-hook, wink and
>others can be described as named signalling events, but there are trunking
>situations where the media gateway may not know the meaning of the
>signalling pattern or the meaning is context sensitive. In such situations,
>the best transport of the indication would be by indicating the ABCD bit
>pattern.
>
>Signalling transition events occur in many situations in the course of a
>call. Often the call control protocol manages these events upon call set-up
>and tear-down, but these events may also occur during a call as part of
>metering or other mechanisms and may need transport. Also in situations
>where a dedicated trunking circuit is constructed, transport of all
>signalling events is useful. So a transport mechanism like that of
>"avt-tones" is suitable.
>
>I would like to propose a transitional signalling event for avt-tones where
>upon signalling transition events messages which indicate the signalling
>pattern can be transmitted. It  would seem that the redundancy mechanism
>proposed in avt-tones is suitable for signalling events of this kind.
>
>Here is some proposed text...
>
>Transitional Signalling Events   
>
>Table X summarizes the signalling events that can apply to a subscriber line
>or trunk. It uses the encoding name "signalling" and the MIME type
>"audio/trunk"
>
>ABCD     encoding        2 state       4 state      16 state
>___________________________________________
>0000           0                    x                  x                x
>1000           1                    x                  x                x
>0100           2                                        x                x
>1100           3                                        x                x
>0010           4                                                          x
>1010           5                                                          x
>0110           6                                                          x
>1110           7                                                          x
>0001           8                                                          x
>1001           9                                                          x
>0101           10                                                        x
>1101           11                                                        x
>0011           12                                                        x
>1011           13                                                        x
>0111           14                                                        x
>1111           15                                                        x
>
>Table X:  ABCD transitional signalling events
>
>The state column indicates the allowed pattern as dictated by the specific
>framing or framing use option.
>
>End of proposed text
>
>A remaining issue is the necessity for a constant low rate transmission of
>the signalling information like FRF.11 does it. Comments appreciated.
>
>Best regards,
>Mike Fox

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Aug 1999 15:37:40 -0400

> a message in the tones draft.

I've added the triple redundancy description to the document. What kind
of document is ITU 366? What's it's full citation?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Marty Borden <[email-masked]>
Date: Thu, 26 Aug 1999 22:45:10 -0400

>of document is ITU 366? What's it's full citation?

Henning,
Sorry for the delay; I am travelling.

The full reference for I366-2 is:

ITU-T Recommendation I.366.2, "AAL Type 2 Service Specific
Convergence Sublayer for Trunking", February, 1999.

This document deals with some of the same problems we consider
except they are placing the samples and data into atm cells.  For
information and clarification I include excerpts from 3 sections.
Basically the "packets" have a 2-bit redundancy field, time stamp,
message type, contents and crc-10.  These are "type 3 packets."

11.2 Triple redundancy and refresh 

The common facility for type 3 packets requiring error correction
is triply redundant transmission. Such packets are sent three
times, with a fixed interval between transmissions.

Each copy of a redundant packet contains the same content, except
in the Redundancy field. The three copies of a packet can be
correlated because they all have the same time stamp.

The Redundancy field is set to values 0, 1, and 2 respectively for
a packet's first, second, and third transmission under triple
redundancy.

ANNEX L Packet format and procedures for channel associated
signalling bits (This annex forms an integral part of this
Recommendation)

L.3     Transmitter procedures

When a transmitter wishes to convey to the receiver a change in
state of the ABCD bits, the CAS packet shall be sent with triple
redundancy at intervals of 5 ms.

Every 5 seconds thereafter the CAS packet is sent to refresh the
ABCD state (with the Redundancy field coded as value 3).

If a new state change is conveyed before the triple redundancy of
a previous state change has completed, the transmitter shall stop
sending packets for the previous state, in order to avoid the
interleaving of two different time stamps.

L.4     Receiver procedures

In order to make full use of triple redundancy without introducing
extra delay variation, the SSCS receiver should wait before
indicating changes in the state of the CAS bits until such time as
it should have received all three copies of a transition. Although
transmitted three times, it only requires one packet to be
received correctly for a change in the state of the CAS bits to be
recognized.

marty
---
Marty Borden
TollBridge Technologies