Alejandro Lengua
2007-Jun-06 12:38 UTC
[asterisk-users] Stanaphone/Asterisk issue: No Audio with SIP to only one provider when switching servers
Hello, did you got your issue solved? I am suffering of the same issue.... On 4/28/07, Hadar Pedhazur <hadar@unorthodox.com> 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: > 342ed93a5d0cda7866f5b7122696e040@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@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! > _______________________________________________ > --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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070606/12831bf7/attachment.htm
Hadar Pedhazur
2007-Jun-06 16:47 UTC
[asterisk-users] Stanaphone/Asterisk issue: No Audio with SIP to only one provider when switching servers
Alejandro Lengua wrote:> Hello, > did you got your issue solved? > I am suffering of the same issue....Hi. I had it off for a few weeks, and then decided to try again, and it "just worked". I didn't change a single thing, only uncommented the register statement that I had previously commented. It's been "reliable" now for the past 2 weeks since I turned it back on. I didn't bother to report here because I didn't have a "solution". I guessed that they changed something on their side, since I did report the problem to them when it first happened (though they didn't respond), but, if you're having the problem, perhaps I just "got lucky". Sorry to hear you're having the problem, I know how frustrating it is!