Subject: [AVT] Re: Additional events for 2833bis-06

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Jan 2005 09:24:47 -0500

This is starting to feel a bit pick-and-choose arbitrary.  I propose instead to 
restrict the core document to DTMF and the base line events, then put the data/FAX 
events into one draft, trunk events into another, and the extended line events 
into a third.  That way specific applications will have specific documents to 
point to.

Flemming Andreasen wrote:
> Greetings
> 
> I've taken a look at the events in 2833bis-06, and it turns out that 
> some of the events that were removed from the -05 version are actually 
> being used:
> 
> 1. ABCD events (144-159), which are used by some GR-303 implementations 
> (incl. PacketCable GR-303 specification)
> 2. The trunk unavailable event (175) , which is used for some PSTN 
> trunking applications.
> 
> I'd like to ask that we add these events back into 2833bis again.
> 
> Thanks
> 
>       Flemming
> 
> 

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
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

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 07 Jan 2005 12:50:20 -0500

I understand your point, but there is also a pragmatic side to this. I 
believe one of the primary motivators for the originally proposed draft 
split was to avoid all the overhead associated with properly specifying 
events that nobody seemed to have implemented anyway. Furthermore, 
unimplemented events would make it difficult to advance to Draft 
standard. Keeping in mind, that the 2833bis has been in the making for a 
long time already, is it worth the effort to make a new set of drafts 
when we are only talking about a relatively small set of events 
currently being used, especially in some of the categories ? I'd prefer 
keeping it manageable and just leave the events that people have 
actually implemented or are referenced elsewhere.

-- Flemming

Tom Taylor wrote:

> This is starting to feel a bit pick-and-choose arbitrary.  I propose 
> instead to restrict the core document to DTMF and the base line 
> events, then put the data/FAX events into one draft, trunk events into 
> another, and the extended line events into a third.  That way specific 
> applications will have specific documents to point to.
>
>> some of the events that were removed from the -05 version are 
>> actually being used:
>>
>> 1. ABCD events (144-159), which are used by some GR-303 
>> implementations (incl. PacketCable GR-303 specification)

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Jan 2005 13:09:19 -0500

The core spec will go to Draft Standard faster, the fewer the events in it, so 
maybe I should restrict it to DTMF only.  Pretty well all the data/FAX events have 
been implemented or at least referenced, including the new V.18 events.  So I 
think it's reasonable to put them all out in one I-D.  The questionable events are 
the line events (basic and particularly extended), since we've not heard of any 
implementations, and most of the trunk group events for the same reason.

I therefore propose that we drop all the line events and all the trunk events 
except the ones you have indicated.  Anyone with objections please speak up.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 07 Jan 2005 15:52:41 -0500

Tom Taylor wrote:

> The core spec will go to Draft Standard faster, the fewer the events 
> in it, so maybe I should restrict it to DTMF only.  Pretty well all 
> the data/FAX events have been implemented or at least referenced, 
> including the new V.18 events.  So I think it's reasonable to put them 
> all out in one I-D.  The questionable events are the line events 
> (basic and particularly extended), since we've not heard of any 
> I therefore propose that we drop all the line events and all the trunk 
> events except the ones you have indicated.  Anyone with objections 
> please speak up.
>
I'm not sure if you are proposing one or two documents here ? If two, 
what is the timeframe for the second one and do we have WG chair buy-in 
(I'd still prefer one since I don't think there is much to be gained 
from removing the currently well-defined events that are already 
implemented or referenced elsewhere) ?

-- Flemming

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Jan 2005 18:41:31 -0500

I am proposing three documents: core spec + DTMF events, data/FAX events, and the 
trunk events you have identified plus perhaps the metering pulse propagation event 
Adrian Soncodi asked for.

Nortel

---

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Jan 2005 18:43:55 -0500

As a postscript: I'm working on them right now, with hopes of getting all but the 
core spec out this weekend.  I have to close with Satish before putting out the 
core spec.

Tom Taylor wrote:
> I am proposing three documents: core spec + DTMF events, data/FAX 
> events, and the trunk events you have identified plus perhaps the 
> metering pulse propagation event Adrian Soncodi asked for.
> 
>>> including the new V.18 events.  So I think it's reasonable to put 
>>> them all out in one I-D.  The questionable events are the line events 
>>> I therefore propose that we drop all the line events and all the 
>>> trunk events except the ones you have indicated.  Anyone with 
>>> objections please speak up.
>>>
>> what is the timeframe for the second one and do we have WG chair 
>> buy-in (I'd still prefer one since I don't think there is much to be 
>> gained from removing the currently well-defined events that are 
>> already implemented or referenced elsewhere) ?
>>
>> -- Flemming
>>
>>
>

---

From: Colin Perkins <[email-masked]>
Date: Sat, 8 Jan 2005 11:26:24 +0000

Seems reasonable to me.
Colin

On 7 Jan 2005, at 23:41, Tom Taylor wrote:

>>> them all out in one I-D.  The questionable events are the line 
>>> events (basic and particularly extended), since we've not heard of 
>>> any implementations, and most of the trunk group events for the same 
>>> reason.
>>>