hmm - that seems correct - I remember experiencing some similar problems(using Cisco IOS gateways, though) which were addressed by "voice call convert-discpi-to-prog"
http://tinyurl.com/5xn8n That command addressed an IOS gateway's tendency to hang up before the in-band message could be played; similarly, it appears that * may not be providing the in-band message to playback to the calling party when an extension is out of service or something. Eric On Fri, 18 Mar 2005 00:06:24 +0100 (CET), Peter Svensson <[EMAIL PROTECTED]> wrote: > On Thu, 17 Mar 2005, Eric Knudson wrote: > > > Trevor, > > > > Nah, I think the response is correct. Take a look at the chart again: > > > > http://www.lkn.ei.tum.de/lehre/kn2/anhangKap4.pdf > > > > look at the incoming setup procedure(1 of 2) (user side). > > > > If you get an incoming SETUP, then you MUST respond with one of the > > following: > > > > CALL PROCEEDING, or ALERTING, or CONNECT, or RELEASE COMPLETE. Follow > > the rest of the logic path to completion for the rest of the call. > > You are not allowed to first respond with a CALL PROCEEDING and then a > RELEASE COMPLETE. In that case DISCONNECT is allowed I think. > > > I suspect that the carrier(since they mentioned a progress indicator) > > expects your equipment to cut through audio and play a message > > back("we're sorry, that extension is not available, blah, blah") or > > play a busy tone or something. > > Peter > > _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users