[asterisk-users] No Audio with SIP to only one provider when switching servers

[Hadar Pedhazur]

I snipped all of the previous data, as I'm trying to "boil down" 
this problem to its essence...

I turned off the firewall for a few seconds, and still got no 
audio. For those that will be suspicious, the commands were:

shorewall stop
shorewall clear

tested connection, no audio

shorewall start

I also have a SIPPhone number, which (obviously), connects via 
SIP. I called that number from the outside, using one of their 
"Access Numbers", and my phone rang and I heard audio in both 
directions (this with the firewall back on), so SIP definitely 
works, just not with StanaPhone.

Then I connected from another server that I run, which is behind a 
NAT router. That server is running 1.2.18 (as is the one that 
isn't working, but is on a public IP). Audio works perfectly with 
this one.

To my knowledge the only difference between them is that the two 
servers that work are both Red Hat 9, with Asterisk 1.2.18 built 
from source. The one that fails is CentOS 5.0, with Asterisk 
1.2.18 built from source. Here is a dump of the active channel 
from the NAT'ed server, which _works_:

   * SIP Call
   Direction:              Incoming
   Call-ID: 
342ed93a5d0cda7866f5b7122696e040 at 66.114.240.26
   Our Codec Capability:   1822
   Non-Codec Capability:   1
   Their Codec Capability:   262
   Joint Codec Capability:   262
   Format                  ulaw
   Theoretical Address:    204.147.183.18:5060
   Received Address:       204.147.183.18:5060
   NAT Support:            RFC3581
   Audio IP:               XX.XX.XX.XX (local)
   Our Tag:                as78cfb201
   Their Tag:              da6aae9eb017f29b6c9de270fb85c352
   SIP User agent:         Sippy
   Original uri:           sip:204.147.183.55:1024
   Caller-ID:              XXXXXXXXXX
   Need Destroy:           0
   Last Message:           Rx: ACK
   Promiscuous Redir:      No
   Route: 
sip:204.147.183.18;ftag=da6aae9eb017f29b6c9de270fb85c352;lr=on
   DTMF Mode:              rfc2833
   SIP Options:            (none)

The only things edited above are the Audio IP, which is my correct 
"local" (before NAT) server address, and my Caller-ID. Everything 
else is unchanged.

Here is the channel with dead audio:

   * SIP Call
   Direction:              Incoming
   Call-ID: 
3d0ccaf3482538f637278d3d2fd5272f at 66.114.240.26
   Our Codec Capability:   1542
   Non-Codec Capability:   1
   Their Codec Capability:   262
   Joint Codec Capability:   6
   Format                  ulaw
   Theoretical Address:    204.147.183.18:5060
   Received Address:       204.147.183.18:5060
   NAT Support:            RFC3581
   Audio IP:               XX.XX.XX.XX (local)
   Our Tag:                as45dbcfef
   Their Tag:              420bab62c5da9eae42686897ae65a385
   SIP User agent:         Sippy
   Original uri:           sip:204.147.183.55:1024
   Caller-ID:              XXXXXXXXXX
   Need Destroy:           0
   Last Message:           Rx: ACK
   Promiscuous Redir:      No
   Route: 
sip:204.147.183.18;ftag=420bab62c5da9eae42686897ae65a385;lr=on
   DTMF Mode:              rfc2833
   SIP Options:            (none)


The same two fields are edited above, and both were correct.

To my eye, these are identical. Both are selecting ulaw, 
correctly. I'm stumped. I guess that I didn't do any packet 
tracing, but I'm not sure what the value of that would be given 
that it's not a firewall problem...

Suggestions welcome!