[asterisk-dev] AST_FRAME_DIGITAL

[Tony Mountifield]

In article <004001c7f6d5$755c03e0$800101df at VALINOR>,
Sergio Garcia Murillo <sergio.garcia at fontventa.com> wrote:
> 
> > In article <003201c7f596$e6827f80$800101df at VALINOR>,
> > Sergio Garcia Murillo <sergio.garcia at fontventa.com> wrote:
> > > 
> > > Just cheking q931 bearer capability:
> > > 
> > > pri debug span 1
> > > Bearer Capability (len= 3)
> > >  Ext: 1  Q.931 Std: 0  Info transfer capability:
> > >          Unrestricted digital information (8)
> > >  Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
> > >  Ext: 1  User information layer 1: H223/H245 data (38)
> > 
> > Was one of the original posts in this thread suggesting that a frame
> > such as the above was being treated by Asterisk as G.711 speech?
> > 
> > If so, surely that is wrong, and the frame/call should be rejected,
> > until such time as the proper handling is designed and implemented.
> > 
> If I'll have to wait untill everything is designed, planned, scheduled,
> then I don't think we won't have it implemented ever.
> The funy thing is that everything is already working, except for the
> tiny detail that we think that we shoul be able to get the correct 
> format of the data so we dn't have to be doing a bit of hacking and
> use ulaw or alaw to trnasport the data from the channel to the application.
> Aslo a patch for correct handling of user information layer 1 in chan_zap
> was done by klaus a few months ago, but still not done into the main source
> code (I think).
> So instead of waiting for nothing to happen, I'd preffered to start the 
> implementation with the current state of art, and try to push for the 
> changes needed to handle everything correctly, and they may even 
> probably mean that I have to recode much parts of my code.
> But once again, I like to do things and make things happen, even if
> they are not done in the *correct* way. 

Hi Sergio, that wasn't the point I was making.

I just wanted to highlight that Asterisk as it is today, WITHOUT the
extra work you have done, should surely reject calls with the above
bearer capability, rather than accept them as if they are speech.

No, I haven't checked the source code, I was just referring to a comment
that it apparently tried to transcode such a data stream from uLaw to aLaw.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org