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: Thu, 4 May 2006 18:06:24 +0200

Hi Tom,

I do not think that  the "original intent of splitting the document" is more
relevant than backward
compatibility issues that would result from IMPLICITLY reclaiming lots of
codepoints previously
allocated in a Standards Track RFC.

"Not hearing" about other codepoints allocated in 2833 does not, IMHO, say
much. One of the
purposes of the IESG LC (as I understand it) is seeking feedback from beyond
the scope of
the WG that has adopted the draft. Nor is the space we are discussing fully
populated
(only about 75%); and I assume that the demand is not high (otherwise you
would definitely
hear about more codepoints :-) 

The base spec stands, IMHO on its own merits because it introduces new
mechanisms
and behaviors (or so you say in the abstract). And establishing a new
registry is the right and 
proper thing to do, too. 

On the other hand, I do not see how adding an explicit reference to a pair
of WG documents 
in different stages of progress to the IANA Considerations section of the
base spec would nullify it. 
You could, if you wish, add a caveat stating something like: 

"At the time when this spec is developed, the authors are aware (or,
actually, are developing :-) 
the following documents allocating additional codepoints in this registry"  

and proceed with briefly describing them. The references could be
informative, but IANA could 
act (or prepare to act)  on them once the base spec is approved.

I must repeat that I see such a reference as an absolute minimum required
for approval of the
base spec.

Hopefully this clarifies my position.

Regards,
                           Sasha

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, May 02, 2006 5:36 PM
> To: Sasha Vainshtein
> Cc: 'Magnus Westerlund'; [email-masked]'; Israel Sasson; 
> [email-masked]'; [email-masked]'; Alik 
> Shimelmits; Tom-PT Taylor
> Subject: Re: Last Call: 'RTP Payload for DTMF Digits, 
> Telephony ones and T elephony Signals' to Proposed Standard
> 
> 
> 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.
> 
> Sasha Vainshtein wrote:
> > 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-rfc2833bisc
as-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
> 
...

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 04 May 2006 11:13:16 -0400

OK, I do appreciate that not progressing 2833biscas at the same time as 
the others has caused problems which must be remedied. The solution is 
perhaps to have a section in the document that describes the changes 
from RFC 2833. This and the abstract would both indicate the disposition 
of the RFC 2833 code points, in detail in the body if you wish. That 
suggests an appendix.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 May 2006 13:14:44 +0200

Hi Tom,

That seems a good solution to this issue. That section is needed anyway 
so please include that in the update.

Cheers

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]

---

From: viswanatha reddy <[email-masked]>
Date: Fri, 5 May 2006 11:00:13 -0700 (PDT)

Hi all,
   
  I am working on fixed point for ILBC codec.
   
  i am in a strange situation. in floating point the output values are varying from 0.2 to 2pow35 where both ends are important for me. 
   
  the situation came in a all pole filter where in i have a buffer of length 40. some times my first value will start at 2 and it will goes to 2pow35 when i caluculate 30th value.
   
  Please give me some suggestion on this.
   
  Below is the C code of the filter that i am talking about
   
  void AllPoleFilter1(
       float *InOut,   /* (i/o) on entrance InOut[-orderCoef] to
                              InOut[-1] contain the state of the
                              filter (delayed samples). InOut[0] to
                              InOut[lengthInOut-1] contain the filter
                              input, on en exit InOut[-orderCoef] to
                              InOut[-1] is unchanged and InOut[0] to
                              InOut[lengthInOut-1] contain filtered
                              samples */
       float *Coef,/* (i) filter coefficients, Coef[0] is assumed
                              to be 1.0 */
       int lengthInOut,/* (i) number of input/output samples */
       int orderCoef   /* (i) number of filter coefficients */
   ){
       int n,k;
         for(n=0;n<lengthInOut;n++){
           for(k=1;k<=orderCoef;k++){
               *InOut -= Coef[k]*InOut[-k];
           }
           InOut++;
       }
   }
   
  Thanks & Regards,
  viswanath..

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.