Subject: RE: Silence compression, a necessary feature for TDM emula tion?

From: Akiva Sadovski <[email-masked]>
Date: Sun, 29 Jun 2003 14:34:40 +0200

Max,
  IMO you may add to chapter 7.5:
    4. ... Channel inactivity detection is outside the scope as well as
channel inactivity signalling to the remote PE (if smb needs this
signalling)

My 2c,
  Akiva

> -----Original Message-----
> From: Max Riegel [mailto:[email-masked]]
> Sent: Thursday, June 26, 2003 11:40 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] Silence compression, a necessary feature 
> for TDM emulation?
> 
> 
> It seems there is consensus, that we should add suppression of unused 
> channels as an optional requirement to the TDM requirements I-D.
> 
> Thank you Yakovv, Amnon and Tim for your explaination of the issues 
> arising with silence compression. I agree that the voice activity 
> detection requireing voice-service specific signal processing 
> belongs to 
> payload specifics and is outside the scope of wire emulation.
> 
> We have already mentioned in chapter 7.5: PSN bandwidth utilization
> 
>     3.  The encapsulation layer MAY provide the ability to 
> save the PSN
>         bandwidth for the structured case by not sending sub-circuits
>         that are inactive.
> 
> This describes the static case of configuring a PW for a 
> fixed number of 
> channels. To extend the ability to dynamically suppress 
> unused channels 
> from transmission I would add:
> 
>     4.  The encapsulation layer MAY enable the dynamic suppression of
>         temporally unused channels from transmission for the 
> structured
>         case.
> 
> I think that such a kind of function makes only sense for structured 
> circuits.
> 
> Bye
> Max
> 
> [email-masked] wrote:
> > As Amnon and Yaakov have pointed out, there are actually 
> two issues here, 
> > suppressing unused channels and silence suppression.
> > 
> > ...
> > 
> > Therefore I would support the suppression of unused 
> channels being an 
> > _optional_ requirement.
> > 
> > Silence suppression is another topic entirely, due to its 
> intensive DSP 
> > requirement. I agree with Yaakov that this is probably 
> outside the scope 
> > of PWE3. Similarly with low-bit rate voice coding. 
> > 
> > Regards,
> > Tim
> > 
> > 
> > 
> > 
> > 
> > "Amnon Ilan" <[email-masked]>
> > Sent by: [email-masked]
> > 26-Jun-2003 08:49 AM
> > Please respond to ailan
> > 
> >  
> >         To:     "'Max Riegel'" 
> <[email-masked]>, <[email-masked]>
> >         cc: 
> >         Subject:        RE: [PWE3] Silence compression, a 
> necessary feature for TDM emulation?
> > 
> > 
> > Max,
> > 
> > 
> >>Is there a reason to add silence compression as an additional
> >>requirement in the TDM requirements I-D?
> >>
> > 
> > IMO TDM requirements should relate to silence compression: it
> > should be an optional feature (not a must).
> > As Yaakov wrote, there are two basic approaches:
> > 1. Adding and tearing-down specific DS0 channels from a trunk\bundle
> >   based on the signaling information.
> >   The requirement from the TDM-PW in this case is to be able to add
> >   and tear-down DS0 in "real-time" (the application should be able
> >   to snoop and parse the specific signaling protocol, but this
> >   has no implication to the TDM-PW itself).
> > 2. Using VAD (voice activity detection) and CNG (comfort noise
> >   generation). The requirement from the TDM-PW in this case is to
> >   be able to send the coded CNG information across the PSN.
> >   This method is more general than the former, since it is
> >   independent of the signaling protocol on the TDM line.
> > 
> > 
> >>Just silence compression, or should we go for some kind of
> >>generic data
> >>compression with reasonable efficiency for voice signals?
> >>
> > 
> > An issue relevant for that question is low-bit-rate coding for voice
> > traffic. There should be an option for both sides of a TDM-PW to
> > signal or have some payload type specifying the coder (with the
> > TDMoIP approach this could be done using AAL2). This should also
> > be an optional feature mentioned in the requirements.
> > 
> > 
> > Amnon.
> > 
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> > 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>