Subject: avt-tones draft additional transitional signalling message.

From: "Fox, Mike" <[email-masked]>
Date: Wed, 18 Aug 1999 17:26:41 -0700

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: "Fox, Mike" <[email-masked]>
Date: Fri, 20 Aug 1999 17:36:36 -0700

Hi Marty,
I did not catch the practical reasoning behind the suggestion for the  5ms
transmission interval after transition. Could you clarify this. In the mean
time I'll just carry on with two points that come to mind anyway.

I have no data at hand, but it would seem that three packet transmissions in
5ms succession have less "reliable" transmission probability than three at
say a 20ms interval when the transmission is into certain packet loss
conditions. Honestly, I do not know if there is a practical difference in
the probabilities.

Also with a quick look at: 
http://www.att.com/cpetesting/pdf/tr41458.pdf
<http://www.att.com/cpetesting/pdf/tr41458.pdf> 
Section 2 I did not see signalling event transitions less than a 30ms
interval. Suggesting a value larger than 5ms (re)transmission interval can
be suitable for signalling events close in time.

I guess my feeling is that if the retransmission period can be the same for
DTMF and other events then the implementation is that much simpler.

But frankly, I'm ok with the 5s periodic transmission, and if there is
general agreement to the 5ms retransmission I'm for it too.

Best regards,
Mike

		-----Original Message-----
		From:	Marty Borden [mailto:[email-masked]]
		Sent:	Friday, August 20, 1999 11:24 AM
		To:	Fox, Mike; Henning Schulzrinne; [email-masked]
		Subject:	Re: avt-tones draft additional transitional
signalling message.

		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:
		>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