Subject: [AVT] RE: Last Call: 'RTP Payload for DTMF Digits, Telephony ones and T elephony Signals' to Proposed Standard

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 2 May 2006 15:25:44 +0200

Hi Magnus,
Thank you for a prompt and informative response.

I must admit that I did not look up
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833biscas-01.txt.
This is because it was neither mentioned in the IESG Last Call announcement
nor referenced in the core
2833bis draft.

The 2833bisdata and 2833biscas drafts seem to fill in most of the gaps in
the code point space left
by the core draft. In particular, my concern about code points for the ABCD
signaling states is 
adequately addressed by the 2833biscas draft.

The problem would not arise if the all the 2833bis drafts were treated by
the IESG as a single block.
After checking with the I-D tracker I see that this is not the case, as the
2833biscas draft has not
been sent to the IESG yet. 

I understand that adding the 2833biscas draft to the block now may be
problematic for the authors 
and/or the WG.

As a minimum, may I suggest explicitly referencing the 2 companion drafts in
the core 2833bis 
document and explaining which kinds of code points are going to be allocated
there?
The logical place for such an explanation would be, IMHO, in the IANA
Considerations section,
so that at least the IANA people could look up these documents and mark the
code points 
allocated there as "reserved" once the core document has been (hopefully,
successfully) 
processed by the IESG.

Regards,
                              Sasha

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, May 02, 2006 9:24 AM
> To: Sasha Vainshtein
> Cc: [email-masked]'; Israel Sasson; 
> [email-masked]'; [email-masked]'; Alik 
> Shimelmits; [email-masked]'
> Subject: Re: Last Call: 'RTP Payload for DTMF Digits, 
> Telephony ones and T elephony Signals' to Proposed Standard
> 
> 
> Hi,
> 
> Have you reviewed the assignments performed in the other 
> 2833bis drafts:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisd
> ata-06.txt
> That populate code points 32-41,43,46,48,49, 52-68.
> And
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisc
> as-01.txt
> That populates code points 128-142,144-159,167,168,174-205.
> 
> Does the complete set of documents (all 3 of them) resolve 
> your issues?
> 
> Cheers
> 
> Magnus
> 
> Sasha Vainshtein wrote:
> > Hi all,
> > I'd like to raise the following issue with 
> draft-ietf-avt-rfc2833bis-12.txt.
> > 
> > Original RFC 2833 has defined encoding of a wide range of 
> telephony events
> > including ABCD (a.k.a. CAS) signaling events. In 
> particular, a contiguous
> > block of 16 code
> > points (from 144 to 159) has been allocated for 16 ABCD 
> signals (ranging
> > from 0 to 15
> > accordingly).
> > 
> > Please note that this encoding is used in in 
> draft-ietf-pwe3-cesopsn-06.txt
> > to carry structure-aware TDM services with ABCD signaling 
> over pseudo-wires.
> > 
> > RFC 2833 did not set up any IANA registry for the tepephony events,
> > but has used the code points from 0 up to (and including) 173 
> > (of the 255 available code points).
> > 
> > Looking at draft-ietf-avt-rfc2833bis-12.txt I've found that:
> > 
> > - this draft, when approved, would OBSOLETE RFC 2833
> > - it sets up a new IANA registry for code points representing
> >   DTMF tones and telephony events BUT populates this registry 
> >   only with 16 code points for the DTMF tones. The rest of the code 
> >   points defined in the original RFC 2833 are essentially 
> INVALIDATED, 
> >   and IANA is free to re-allocate them as it sees fit.
> > 
> > IMHO this could potentially create multiple backward compatibility
> > issues, especialy if, as in the case of ABCD signals, contiguous
> > blocks of code points are desirable for specific applications.
> > 
> > Hence I suggest to RETAIN all the code points allocated in 
> the original 
> > RFC 2833 in the mew IANA registry. This would prevent any backward 
> > compatibility issues while still leaving 83 free code 
> points (174 to 255) 
> > for IANA to distribute. If this is not enough, some "unused 
> code point 
> > reclamation process" could be run. 
> > 
> > IMHO this could be achieved by incorporating the relevant 
> parts of the 
> > original RFC 2833 into the new draft.
> > 
> > Hopefully these notes will be useful.
> > 
> > Regards,
> >        Sasha Vainshtein
> > 
> >> -----Original Message-----
> >> From: The IESG [mailto:[email-masked]]
> >> Sent: Thursday, April 06, 2006 9:30 PM
> >> To: IETF-Announce
> >> Cc: [email-masked]
> >> Subject: Last Call: 'RTP Payload for DTMF Digits, Telephony 
> >> Tones and Telephony Signals' to Proposed Standard 
> >>
> >>
> >> The IESG has received a request from the Audio/Video 
> >> Transport WG to consider 
> >> the following documents:
> >>
> >> - 'RTP Payload for DTMF Digits, Telephony Tones and Telephony 
> >> Signals '
> >> <draft-ietf-avt-rfc2833bis-12.txt> as a Proposed Standard
> >> - 'Definition of Events For Modem, FAX, and Text Telephony 
> Signals '
> >> <draft-ietf-avt-rfc2833bisdata-06.txt> as a Proposed Standard
> >>
> >> The IESG plans to make a decision in the next few weeks, 
> and solicits
> >> final comments on this action. Please send any comments to the
> >> [email-masked] or [email-masked] mailing lists by 2006-05-04.
> >>
> >> The file can be obtained via
> >> 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-12.txt
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisd
> ata-06.txt
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 02 May 2006 11:35:50 -0400

Sorry to cause you alarm, but mentioning the other documents by name in 
the base specification would nullify the reason for splitting the 
document in the first place. The whole point was to allow requests for 
new event code points to stand on their own merits while preserving 
backward compatibility to the extent to which 2833 seems to have been 
implemented. We dropped the whole set of telephone line signalling 
events, for instance, because no one spoke up for them. Nevertheless, if 
someone sees a need for them in the future, they are free to introduce a 
new draft.

As I think about it, it might be possible to add something in the 
abstract, which talks about changes from RFC 2833.

As for the current status of 2833biscas: I gave it lower priority 
because I was unaware of any reference to these code points outside of 
some PacketCable documentation. The missing piece of work is a careful 
review of congestion implications. Otherwise, there has been no comment 
on this document for nearly a year. Given your document dependency, I'd 
better finish my piece of the work and ask for WGLC.

> allocated there as "reserved" once the core document has been (hopefully,
...