<div>Sorry guys, seems I'm a dumb-ass. I love it how after writing these long e-mails with all the descriptions of how things interact, I figure out the problem based on my words alone. I copied the configuration files from a system that had an internal IP address (
192.168.X.X) to one that had an external IP. Only way to get an internal IP address Asterisk box to work is to set the localnet and external options in sip.conf. So all these problems were because the Asterisk box thought its IP address was different than its real address.
</div>
<div> </div>
<div>While this issue was all mine, I'm surprised that Asterisk didn't notice that its IP address wasn't even within the "LOCALNET" IP block and therefore couldn't transmit to the local range. If Asterisk's IP isn't in the local range, it should at least give an error for that if not ignore the setting for the external IP. I'm always surprised by applications that allow you to set a data path (route) which you can't reach with your current IP and Netmask settings. I expect there is a reason for this, but as a network tech I haven't figure out one.
</div>
<div> </div>
<div>Thanks anyways guys. This list at least allows me to dwell better on the Asterisk issues I have. By talking things out I tend to figure out the problem. 5 hours of work and I get no where, I send an e-mail to this list and 5 minutes later I've figured it out. Have a nice night!
</div>
<div> </div>
<div>/Nicholas Blasgen<br><br> </div>
<div><span class="gmail_quote">On 10/2/07, <b class="gmail_sendername">Nicholas Blasgen</b> <<a href="mailto:nicholas@blasgen.com">nicholas@blasgen.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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><span class="sg"><br>
-- <br>/Nick </span></blockquote></div>