Hello, did you got your issue solved? I am suffering of the same issue....
On 4/28/07, Hadar Pedhazur <[EMAIL PROTECTED]> wrote:
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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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! _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
