[asterisk-dev] RTP Audio Problem, No Audio Passed

[Nicholas Blasgen]

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.

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.

GOOD BOX: Asterisk SVN-branch-1.4-r81291
BAD BOX: Asterisk SVN-branch-1.4-r83348

======== CALL FILE ==========
Channel: Local/nick at realtimedb
MaxRetries: 0
RetryTime: 15
WaitTime: 30
Application: Macro
Data: which-line|4084979796
===========================

====== MINOR VERBOSE ======
======== GOOD BOX =========
    -- Executing Dial("Local/nick at realtimedb-fe60,2", "
Local/4083951234 at outgoing|20")
    -- Called 4083951234 at outgoing
[ . . . ]
    -- Executing [s at macro-which-line:9]
Dial("Local/4083951234 at outgoing-5d4c,2",
"SIP/trunk0/14083951234") in new stack
    -- Called trunk0/14083951234
    -- SIP/trunk0-09dabf40 is making progress passing it to
Local/4083951234 at outgoing-5d4c,2
    -- Local/4083951234 at outgoing-5d4c,1 is making progress passing it to
Local/nick at realtimedb-fe60,2
    -- SIP/trunk0-09dabf40 answered Local/4083951234 at outgoing-5d4c,2
    -- Local/4083951234 at outgoing-5d4c,1 answered Local/nick at realtimedb-fe60
,2
[ . . . ]
    -- Executing [s at macro-which-line:9] Dial("Local/nick at realtimedb-fe60,1",
"SIP/trunk0/14084979796") in new stack
    -- Called trunk0/14084979796
  == Spawn extension (macro-which-line, s, 9) exited non-zero on '
Local/4083951234 at outgoing-5d4c,2' in macro 'which-line'
  == Spawn extension (macro-which-line, s, 9) exited non-zero on '
Local/4083951234 at outgoing-5d4c,2'
  == Spawn extension (realtimedb, nick, 2) exited non-zero on '
Local/nick at realtimedb-fe60,2'
    -- SIP/trunk0-09d8f2c8 is making progress passing it to
SIP/trunk0-09dabf40
==========================
======== BADD BOX =========
    -- Executing Dial("Local/nick at realtimedb-7bf7,2", "
Local/4083951234 at outgoing|20")
    -- Called 4083951234 at outgoing
[Oct  2 22:26:37] NOTICE[2721]: cdr.c:434 ast_cdr_free: CDR on channel
'SIP/trunk0-08f9f610' not posted
[ . . . ]
    -- Executing [s at macro-which-line:9]
Dial("Local/4083951234 at outgoing-bb40,2",
"SIP/trunk0/14083951234") in new stack
    -- Called trunk0/14083951234
    -- SIP/trunk0-08f8bc88 is making progress passing it to
Local/4083951234 at outgoing-bb40,2
    -- Local/4083951234 at outgoing-bb40,1 is making progress passing it to
Local/nick at realtimedb-7bf7,2
    -- SIP/trunk0-08f8bc88 answered Local/4083951234 at outgoing-bb40,2
    -- Local/4083951234 at outgoing-bb40,1 answered Local/nick at realtimedb-7bf7
,2
[Oct  2 22:26:42] WARNING[2719]: pbx.c:5141 ast_pbx_outgoing_app:
Local/nick at realtimedb-7bf7,1 already has a call record??
[Oct  2 22:26:42] NOTICE[2719]: cdr.c:434 ast_cdr_free: CDR on channel
'SIP/trunk0-08f9a950' not posted
[ . . . ]
    -- Executing [s at macro-which-line:9] Dial("Local/nick at realtimedb-7bf7,1",
"SIP/trunk0/14084979796") in new stack
    -- Called trunk0/14084979796
    -- SIP/trunk0-08fa4960 is making progress passing it to
Local/nick at realtimedb-7bf7,1
==========================
==========================

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.

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.

-- 
/Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20071002/4ba3c34e/attachment-0001.htm