Subject: RE: [AVT] CAS signalling events: draft-ietf-avt-rfc2833biscas-00.txt

From: "Oren Peleg" <[email-masked]>
Date: Tue, 1 Mar 2005 12:48:19 +0200

I have a problem with the ABCD state definition. The ABCD bits should
have a respective bit in the state regardless to the trunk framing
method. E.g. when on A & B are used & A=0 & B=1, the state may be 0x0100
up to 0x0111. The important issue here is that the bit in the state for
A, B, C & D is constant no matter what is the framing method. This way
if the framing method is different between sender & receiver, the biscas
still support it. Also may be recommended to duplicate the AB value to
the CD bits when only A & B are used. This will help some different
framing methods to be synced.

Regards,

Oren P.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Taylor
Sent: Sunday, February 06, 2005 9:53 PM
To: [email-masked]
Subject: [AVT] CAS signalling events:
draft-ietf-avt-rfc2833biscas-00.txt

I have just submitted draft-ietf-avt-rfc2833biscas-00.txt to capture the

trunk-oriented signalling events from RFC 2833, as modified in earlier
2833bis 
work.  There are some key deviations from the events as presented in 
draft-ietf-avt-rfc2833-05.txt.  These have to do with line event
signalling for 
signalling systems No. 5, R1, and R2, and the mapping of ABCD bits to
event codes. 
  The new mappings are my best attempt at consistency with published
documents.

The basic mapping of ABCD states to event codes was changed when I found
a 
PacketCable specification using some of those events from RFC 2833.  It
appeared 
that they assumed a mapping where the A bit is the high-order bit of a
4-bit 
state, where draft-ietf-avt-rfc2833-05.txt suggested that the A-bit
would be the 
low-order bit.  I changed the text to be consistent with the PacketCable
mapping. 
  However, the R2 line code mappings are a bit ugly as a result, with
the event 
codes differing for the same line state depending on whether analog or
digital 
line signalling is being used.

Could anyone who has used the ABCD events in the past look over the
document to 
see if it still works for them?

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

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

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

---

From: Tom Taylor <[email-masked]>
Date: Fri, 04 Mar 2005 15:42:47 -0500

> framing methods to be synced.

I just thought I would summarize the consequences of this change as I extend the 
logic throughout the document.  It probably improves consistency.

Basic mapping of single bit and two bit states to event codes:

A = 1 mapped to b1111, event code 159
A = 0 mapped to b0000, event code 144
AB = 11 mapped to b1111, event code 159
AB = 10 mapped to b1010, event code 154
AB = 01 mapped to b0101, event code 149
AB = 00 mapped to b0000, event code 144

Signalling System No. 5 line signals:
====================================

Both 2400 Hz and 2600 Hz present (clear-forward and release guard):
     still b0000 = event code 144 (no change)

Only 2400 Hz present (seizing, forward acknowledgement, answer):
     b0101 = event code 149 (change from 145)

Only 2600 Hz present (proceed-to-send, busy flash, clear-back, and forward transfer):
     b1010 = event code 154 (change from 146)

Neither tone present (pause between signals, stable state):
     b1111 = event code 159 (change from 147)

Signalling System R1 line signals:
=================================

2600 Hz present (on-hook):
     still b0000 = event code 144 (no change)

2600 Hz absent (off-hook):
     b1111 = event code 159 (change from 145)

Signalling System R2 analogue line signals:
==========================================

3825 Hz tone present (on-hook):
     still b0000 = event code 144 (no change)

3825 Hz tone absent (off-hook):
     b1111 = event code 159 (change from 145)

Signalling System R2 digital line signals:
=========================================

Note that the A bit from each end indicates the hook state, while the B bit 
indicates failure conditions (forward) and assignment of switching equipment 
(backward).

On-hook and idle (either end):
     b1010 = event code 154 (change from 146)

Calling end off-hook:
     b0000 = event code 144 (no change)

Called end line on-hook, switching equipment engaged (seizure ack / clear-back / 
blocked):
     b1111 = event code 159 (change from 147)

Called end line off-hook, switching equipment engaged (answered):
     b0101 = event code 149 (change from 145)

The inconsistency between interpretation of the A bit (1 = line idle) and the B 
bit (0 = switch idle) causes these codes to differ from those for similar states 
using analogue signalling.

Tom Taylor