Summary:ASTERISK-03108: SIP transfers leave * unresponsive
Reporter:Trevor Peirce (trev)Labels:
Date Opened:2004-12-27 20:03:49.000-0600Date Closed:2011-06-07 14:00:45
Versions:Frequency of
Environment:Attachments:( 0) gdb.txt
( 1) startasterisk.txt
Description:701 calls 702 and everything works as expected.  701 transfers 702 to 703.  As far as 701 is concerned every thing is OK and is now out of the picture.  703 is never alerted that the call is transferred.  702 briefly hears MOH and then silence.  Neither 701, 702, or 703 can place any more calls.


  -- SIP Seeding 'testing701' at testing701@ for 3600
  -- Added extension 'testing701' priority 1 to testing_debug
  -- Executing Macro("SIP/testing701-bc37", "testing|testing") in new stack
  -- Executing Dial("SIP/testing701-bc37", "SIP/testing702|20|") in new stack
  -- SIP Seeding 'testing702' at testing702@ for 3600
  -- Added extension 'testing702' priority 1 to testing_debug
  -- Called testing702
  -- SIP Seeding 'testing702' at testing702@ for 3600
  -- Added extension 'testing702' priority 1 to testing_debug
  -- SIP/testing702-56b1 is ringing
  -- SIP/testing702-56b1 answered SIP/testing701-bc37
  -- Started music on hold, class 'default', on SIP/testing702-56b1
  -- Stopped music on hold on SIP/testing702-56b1
== Spawn extension (macro-testing, sf, 103) exited non-zero on 'SIP/testing701-bc37' in macro 'testing'
== Spawn extension (mycontext_go, 701, 4) exited non-zero on 'SIP/testing701-bc37'
== Starting SIP/testing702-56b1 at mycontext,703,0 failed so falling back to exten 's'
== Starting SIP/testing702-56b1 at mycontext,s,0 still failed so falling back to context 'default'
Dec 27 17:13:42 WARNING[16886]: pbx.c:1942 ast_pbx_run: Channel 'SIP/testing702-56b1' sent into invalid extension 's' in context 'default', but no invalid handler

This looks to me like * is looking for priority 0 which doesn't exist.  I have omitted my configuration since all extensions can call and conference call each other fine.  It's the SIP transfer that fails.  

Am using latest CVS, though this has been happening for a week or two now.
Comments:By: Trevor Peirce (trev) 2004-12-27 20:47:37.000-0600

Actually, just to answer before Qs are asked here are some global options from sip.conf [peers themselves are from realtime, and only have minimal columns].


By: Mark Spencer (markster) 2004-12-28 02:51:06.000-0600

Can you produce both the sip debugs and a full backtrace of all threads, as this sounds like a deadlock?  It would likely also be helpful if you could perform a "make clean ; make valgrind ; make install" before doing the backtrace.

By: Trevor Peirce (trev) 2004-12-28 16:39:30.000-0600

I was just downloading gbd and updating to the latest cvs... looks like a patch commited by anthm fixed this.

By: Trevor Peirce (trev) 2004-12-28 19:25:39.000-0600

A new issue with current CVS is now causing my * to not even start anymore.

See startasterisk.txt for the console output.  I am not quite sure what information is needed from gdb (if any) but I have attached gdb.txt per suggestions from the wiki.

By: Trevor Peirce (trev) 2004-12-29 03:43:35.000-0600

Let's close this bug.  These problems may be the result of an error on my system... some other things are active very oddly.

By: Mark Spencer (markster) 2004-12-29 07:38:46.000-0600

Suspended at the user's request.  Feel free to reopen if need be.