[asterisk-dev] AST_FRAME_DIGITAL

Sergio Garcia Murillo sergio.garcia at fontventa.com
Fri Sep 14 09:36:57 CDT 2007


----- Original Message ----- 
From: "Tony Mountifield" <tony at softins.clara.co.uk>
To: <asterisk-dev at lists.digium.com>
Sent: Friday, September 14, 2007 4:12 PM
Subject: Re: [asterisk-dev] AST_FRAME_DIGITAL


> 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.

Ok, sorry to have misunderstood you.. too much tension arround here
latelly :)

>
> 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.
>

In fact it does, the call is considered as voice and it returns the default
alaw or
ulaw format, that why we are asking for the digital frame type.

Best regards
Sergio




More information about the asterisk-dev mailing list