I've looked, poked, and hoped, but I can't seem to make * understand the difference between a SIP channel being busy or not being there. Both come up as 'busy'. I would expect the unregistered SIP to be seen as unavailable. Am I just missing something obvious, again? Tim -->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> Tim Sailer >< Coastal Internet, Inc. << >> Network and Systems Operations >< PO Box 726 << >> http://www.buoy.com >< Moriches, NY 11955 << >> tps@buoy.com >< (631) 399-2910 (888) 924-3728 << >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
That's just the way Asterisk's dial command works. On Mon, 2004-02-09 at 13:16, Tim Sailer wrote:> I've looked, poked, and hoped, but I can't seem to make * understand > the difference between a SIP channel being busy or not being there. > Both come up as 'busy'. I would expect the unregistered SIP to be seen > as unavailable. Am I just missing something obvious, again? > > Tim-- Go to http://www.digium.com/index.php?menu=documentation and look at the "Unofficial Links" section. This section has links to a wide variety of 3rd party Asterisk related pages. My page is the "Asterisk Resource Pages". BTEL Consulting 504-899-1387 or 850-484-4545 or 877-677-9643
Hi!> I've looked, poked, and hoped, but I can't seem to make * understand > the difference between a SIP channel being busy or not being there. > Both come up as 'busy'. I would expect the unregistered SIP to be seen > as unavailable. Am I just missing something obvious, again?You are right, this is a true problem. There might be a workaround, however: As an illustration at the CLI do a "database show SIP/Registry" or refine this to "database show SIP/Registry/username". Now use the same approach with DBget() in your dialplan. Of course this works only with dynamic SIP clients that do register; in case of static SIP clients you could use AGI or System() to ping the client first... In general I think this belongs into the discussion "we need better = more detailed return codes from the Dial() command". Cheers, Philipp
Tim Sailer wrote:> I've looked, poked, and hoped, but I can't seem to make * understand > the difference between a SIP channel being busy or not being there. > Both come up as 'busy'. I would expect the unregistered SIP to be seen > as unavailable. Am I just missing something obvious, again?I've heard the same from other sources. Maybe the fix to another problem in the SIP channel a week ago causes this. Mark? You know the 0.0.0.0 patch? I don't think it delivers unavailable if not registred. /O
Tim Sailer said:> I've looked, poked, and hoped, but I can't seem to make * understand > the difference between a SIP channel being busy or not being there. > Both come up as 'busy'. I would expect the unregistered SIP to be seen > as unavailable. Am I just missing something obvious, again? > > Tim > ^Tim, I use the following in my dialplan to distinguish between Unavailable (ie: did not answer), Busy and Channel doesn't exist. ChanisAvail goes to n+101 if the channel is NOT avail. There is probably a better way to exit the sequence but that is what works for me. exten => 11,1,Macro(stdexten,11,SIP/11) Below is the macro for the above... Have tested it with IAX2, SIP and MGCP. The first argument is the macro name, 2nd is the voicemailbox, 3rd is the Channel to dial. [macro-stdexten] exten => s,1,ChanisAvail(${ARG2}) exten => s,2,Dial(${ARG2},20,Ttr) exten => s,102,Voicemail2(u${ARG1}) exten => s,103,Hangup exten => s,104,Voicemail2(b${ARG1}) exten => s,105,Hangup LIke I said.. its messy but does work. Robert Friedrichshafen, Germany