Well, it appears that the all to sip_rtp_read dies when I call ast_read(p->owner) for some reason..
See what I don't get is that when I call ast_set_read_format, I give it a channel and a format. when I call ast_dsp_call_progress I give it a DSP and a ast_frame what makes the ast_frame be in the right format? needless to say, I get: dsp.c:1154 ast_dsp_call_progress: Can only check call progress in signed-linear frames any ideas? On 1/17/07, Leo Ann Boon <[EMAIL PROTECTED]> wrote:
Brett List wrote: > My SIP Provider (A large major carrier) passes me calls this way. And > no, they won't disable early media and provide an appropriate > supervision code. > > In fact, all carriers we've tested have transmitted the call this way. > Even my cell phone gives me the tri-tone without "connecting" In my part of the world, the telcos will drop the call immediately and return the cause code. > > Yes, chan_sip would need to be modifed. That is the work I am requesting. The problem with goertzel detection in G.729 is not trivial. Too much spectral energy was lost in the transcoding. I'm speaking from experience with DTMF detection in G.729. > > For what it's worth, I've attempted to modify chan_sip in the > sip_rtp_read func to include adding a dsp with ast_dsp_new, converting > to SLINEAR with ast_set_read_format and then passing it to > ast_dsp_call_progress. But it doesn't seem to be doing anything at > all.. I've been performing my test on G.711. Your logic is sound. Did you dump out the return values? Leo _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
