Subject: [AVT] 2833bis: ABCD bits

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 09 Dec 2002 16:14:10 -0500

Currently, the ABCD bits don't quite fit into the 2833 framework. They 
are not really "tones", they are not associated with any particular 
audio session and they are not really events (since they persist as 
states). Since 2833 is not meant to replace a T1-over-IP (PWE) protocol, 
it is not clear whether these belong.

If anybody is using these events, please speak up as to why this should 
be done using 2833.

Henning

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Rajesh Kumar <[email-masked]>
Date: Mon, 09 Dec 2002 21:47:03 -0800

Henning,
There are VoIP trunking solutions that use the RFC2833 telephone events to 
transport ABCD signaling. These operate at a DS0 rather than a T1/E1 level. 
Granted some overlap with the PWE3 work, I still recommend retaining the 
RFC2833 events so as to not obsolete current implementations. Further, the 
PWE3 work is not finalized, and some of the PWE3 proposals do recommend the 
use of RFC2833 to transmit ABCD signaling.

Rajesh

At 04:14 PM 12/9/2002 -0500, Henning Schulzrinne wrote:
>Currently, the ABCD bits don't quite fit into the 2833 framework. They are 
>not really "tones", they are not associated with any particular audio 
>session and they are not really events (since they persist as states). 
>Since 2833 is not meant to replace a T1-over-IP (PWE) protocol, it is not 
>clear whether these belong.
>
>If anybody is using these events, please speak up as to why this should be 
>done using 2833.
>
>Henning
>

---

From: Stephen Casner <[email-masked]>
Date: Mon, 9 Dec 2002 22:42:35 -0800 (PST)

Rajesh,

> transport ABCD signaling. These operate at a DS0 rather than a T1/E1 level.

Can you describe this further?  Is the DS0 dedicated to just carrying
the ABCD signaling using 2833, or does it provide other functionality
as well?

                                                        -- Steve

---

From: Rajesh Kumar <[email-masked]>
Date: Tue, 10 Dec 2002 00:07:18 -0800

Steve,

The DS0 carries normal bearer information and is encapsulated, say, in a 
G729 RTP packet.  Signaling is carried via RFC 2833. Other spins on this 
theme are the use of RTP multiplexing, with and without header compression. 
Note that these channels are provisioned.

These are real applications that would be orphaned if the AVT would disown 
RFC2833 ABCD signaling.

Rajesh

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Tue, 10 Dec 2002 08:26:13 -0500

Henning/Steve/Colin,

Henning, on a theoretical level, is correct in that "dc-signalling states" 
are not
in the same class as other RFC2833 "tones" information. But like Rajesh, I
would ask that they remain in the current/future RFC2833. Since Steve asked
a rudimentary question in the thread below ... let me explain using some
historical context. My apologies if some of the information is below the
understanding of many listeners.

Analog/touch tone phones used *both* tones and so-called dc-signaling (on-hook,
off-hook, hook-flash, winks, reverse battery stuff) for signaling. Although 
each
state persists for a minimum interval (and on-hook for quite a while in most
cases) ... it is the signaling transitions that are the most interesting. 
And in the
case of dial-pulsing (rotary phones) ... must be conveyed with a modicum of
transition fidelity to get the on/off-hook cadences corresponding to the 
1-9 digits
correct at the "decoding end". Note that the "decoding end" is usually - *but
not exclusively* - a class 5 switch (we will need this point later).

When digital transport systems came along (long before SS7) ... this signaling
needed to be carried in the media (in the DS0 stream). The tones were not a
problem ... they were in the media already. The dc-signaling states were
munged into a classification that contained 16 possible states .... and
hereafter coded using four bits called ABC and D bits. These bits are sent
serially, one in every eight (8-bit mu/A-law encoded) PCM octet (in the
least significant bit position for those who care). The *actual bit position*
of the A, B, C or D bit ... is determined by the overall framing of the T1
framing bits. In other words ... you need the whole T1 stream to "find the
ABCD bits" in a given DS0 (without resorting to statistical heuristics to
infer their position). It is here where Henning might think this has more to
do with PWE than a DS0 issue.

I'd maintain that the ABCD bits encoded in the DS0 stream as a function
of T1 framing bits is simply convenience given technology at the time of
the technology's invention. Clearly also is that the ABCD bits are signaling
associated with the DS0 .... a "9" digit can be sent equivalently as a
touch tone or a digit pulse stream (with the ABCD bits transitioning from
off-hook to on-hook and back again nine times). In this context, the
ABCD "state" (transition) information is equally important to the operation
of the signaling on the DS0 as the "tones" in RFC2833 are. As mentioned
above, the system receiving the bits *is not always the first class 5 switch*
For example, private line automatic ringback arrangements (PLAR) over IP
that equipment suppliers support today do so with RFC2833. When the DS0
for PLAR is "trunked" via IP to a far away location (without the context of a
T1 or PWE) .. one needs to convey the ABCD information as well as any
tones.

I believe that Rajesh was using this last point to say that the ABCD bits
"operate" (i.e., are used) at a DS0 level ... even though they historically
have been "framed" at a T1 level.

I hope this helps answers: 1) Steve's question, 2) explains why Henning
is "theoretically correct" that tones are not dc-signaling states, 3) explains
why ABCD bit transitions are equally important as some RFC2833 tones
in some EXISTING applications and 4) supports Rajesh's concern that ABCD
bits "operate on a DS0 level" and should remain in RFC2833.

Since the industry still needs ABCD bits to support existing arrangements, I
would like to see them remain in RFC2833.

Michael Ramalho

>the ABCD signaling using 2833, or does it provide other functionality

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.941.708.4650 <- new!
Cell: +1.941.544.2844 <- new!

---

From: Stephen Casner <[email-masked]>
Date: Tue, 10 Dec 2002 10:50:57 -0800 (PST)

Michael,

Thanks.  Your explanation of the ABCD-bit signaling was helpful.

                                                        -- Steve

---

From: "Rex Coldren" <[email-masked]>
Date: Tue, 10 Dec 2002 16:00:43 -0700

All,
   I agree with Rajesh and Michael that the ABCD events remain in RFC 2833.
Michael's explanation gives a good theoretical angle and you can look at the
PacketCable Line Control Signaling Technical Report (www.packetcable.com)
for a practical application example.

Regards,
Rex Coldren

---

From: Ranjith Mukundan <[email-masked]>
Date: Fri, 13 Dec 2002 15:28:00 +0530

in case of T1, the ABCD bits (SF or ESF) are 'robbed' from the DS0 that also
tranports bearer.

in case of E1 & J1 (R1/R2 based CAS systems), typically the 16th timeslot (off
the available 32), is *dedicated* to carry the ABCD bits to indicate the line
signaling states (off hk, on hk etc). It's only the register signaling (used for
transport of address info, calling line category etc) that gets transported as
tones over the DS0 allocated for speech after the call matures to 'answer' state.

Doesn't make sense if PWE has to be used to tranport line signaling and RFC2833
for register signaling to manage a session within one call for E1/J1 based CAS
trunking over IP.

Either way, I feel, RFC2833 *should* continue to have support for these ABCD
bits.

- ranjith..