I've got two Asterisk boxes. One has been designed as a copy-cat of the main production one. I've simply installed Asterisk and copied over all the configuration files from the working production server to a newly setup server. They're both using ViaTalk SIP trunks for outgoing calls, though they have different numbers they're using. Production server, which works just fine, is sitting in the DMZ of an office NAT. New server is a dedicated colocation with it's own IP address. If you can't tell, I'm having issues with the new system. The thing I'm trying to fix, which I think will fix any other issues, is that I can't hear the "ring" audio on the calls. I can't hear any audio period (niether party can hear eachother once connected), but I'd expect to hear the "ring" sound in any situation.
<br><br>If I write a call file to call one phone number and execute the Dial application to call another, both systems have no issue. But if I dial a "Local" channel and use that to call the first number, it works just great on the old box but doesn't work on the new box.
<br><br>GOOD BOX: Asterisk SVN-branch-1.4-r81291<br>BAD BOX: Asterisk SVN-branch-1.4-r83348<br><br>======== CALL FILE ==========<br>Channel: Local/nick@realtimedb<br>MaxRetries: 0<br>RetryTime: 15<br>WaitTime: 30<br>Application: Macro
<br>Data: which-line|4084979796<br>===========================<br><br>====== MINOR VERBOSE ======<br>======== GOOD BOX =========<br> -- Executing Dial("Local/nick@realtimedb-fe60,2", "Local/4083951234@outgoing
|20")<br> -- Called 4083951234@outgoing<br>[ . . . ]<br> -- Executing [s@macro-which-line:9] Dial("Local/4083951234@outgoing-5d4c,2", "SIP/trunk0/14083951234") in new stack<br> -- Called trunk0/14083951234
<br> -- SIP/trunk0-09dabf40 is making progress passing it to Local/4083951234@outgoing-5d4c,2<br> -- Local/4083951234@outgoing-5d4c,1 is making progress passing it to Local/nick@realtimedb-fe60,2<br> -- SIP/trunk0-09dabf40 answered
Local/4083951234@outgoing-5d4c,2<br> -- Local/4083951234@outgoing-5d4c,1 answered Local/nick@realtimedb-fe60,2<br>[ . . . ]<br> -- Executing [s@macro-which-line:9] Dial("Local/nick@realtimedb-fe60,1", "SIP/trunk0/14084979796") in new stack
<br> -- Called trunk0/14084979796<br> == Spawn extension (macro-which-line, s, 9) exited non-zero on 'Local/4083951234@outgoing-5d4c,2' in macro 'which-line'<br> == Spawn extension (macro-which-line, s, 9) exited non-zero on '
Local/4083951234@outgoing-5d4c,2'<br> == Spawn extension (realtimedb, nick, 2) exited non-zero on 'Local/nick@realtimedb-fe60,2'<br> -- SIP/trunk0-09d8f2c8 is making progress passing it to SIP/trunk0-09dabf40
<br>==========================<br>======== BADD BOX =========<br> -- Executing Dial("Local/nick@realtimedb-7bf7,2", "Local/4083951234@outgoing|20")<br> -- Called 4083951234@outgoing<br>[Oct 2 22:26:37] NOTICE[2721]:
cdr.c:434 ast_cdr_free: CDR on channel 'SIP/trunk0-08f9f610' not posted<br>[ . . . ]<br> -- Executing [s@macro-which-line:9] Dial("Local/4083951234@outgoing-bb40,2", "SIP/trunk0/14083951234") in new stack
<br> -- Called trunk0/14083951234<br> -- SIP/trunk0-08f8bc88 is making progress passing it to Local/4083951234@outgoing-bb40,2<br> -- Local/4083951234@outgoing-bb40,1 is making progress passing it to Local/nick@realtimedb-7bf7
,2<br> -- SIP/trunk0-08f8bc88 answered Local/4083951234@outgoing-bb40,2<br> -- Local/4083951234@outgoing-bb40,1 answered Local/nick@realtimedb-7bf7,2<br>[Oct 2 22:26:42] WARNING[2719]: pbx.c:5141 ast_pbx_outgoing_app:
Local/nick@realtimedb-7bf7,1 already has a call record??<br>[Oct 2 22:26:42] NOTICE[2719]: cdr.c:434 ast_cdr_free: CDR on channel 'SIP/trunk0-08f9a950' not posted<br>[ . . . ]<br> -- Executing [s@macro-which-line
:9] Dial("Local/nick@realtimedb-7bf7,1", "SIP/trunk0/14084979796") in new stack<br> -- Called trunk0/14084979796<br> -- SIP/trunk0-08fa4960 is making progress passing it to Local/nick@realtimedb-7bf7
,1<br>==========================<br>==========================<br><br>The main thing to note from these is that in the case of the "good" box, you see it drop the "masq" names and when the call is getting patched it's refering to them only as making progress connecting trunk0-id1 to trunk0-id2. In the case of the bad box, it's connecting trunk0-id1 to an extension that I guess isn't properly linked.
<br><br>When I turn on RTP debugging, the BAD system doesn't show anything ever. The GOOD system shows plenty of RTP traffic while the call is being setup but nothing after it starts to ring.<br><br>-- <br>/Nick