asterisk users - Jun 2007 - 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

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!