This is what is shown when the call connects with:
sip show channel
The conference suite from another provider on internal IP is waiting
for an ACK on port 5605, but * is sending it back to port 2289
Internal between Asterisk and another Conference suite:
* SIP Call
Direction:
On 23/05/07, Mojo with Horan Company, LLC [EMAIL PROTECTED] wrote:
Does the non-Asterisk server _answer_ the line? :)
Hi, sorry. I have been away on site doing 8 work ;-)
Yes, it does. We've done a packet trace and it appears that * sends an
ACK back on the wrong port, i.e. not 5605 like a
On 23/05/07, Nick Seraphin [EMAIL PROTECTED] wrote:
The 2 most common problems I've seen for no audio in one or both
directions is usually either a firewall (which you already said you don't
have) or a CODEC problem.
Make sure both sides are negotiating the same CODEC. I've often seen
Dear All,
I have a tiny dial plan like:
[testing]
exten = 454,s,Ringing()
exten = 454,n,Wait(4)
exten = 454,n,Dial(SIP/[EMAIL PROTECTED]:5605,10)
exten = 454,n,Hangup
This connects fine when I dial 454 from any extension in my system,
but there is never any audio?
Where can I start to look
Gavin,
Does the Asterisk server's route to 192.168.45.18 traverse a firewall or
router that may be blocking non-SIP ports that are dynamically allocated?
SDP -- part of the SIP INVITE transaction payload -- negotiates arbitrary
ports between the two endpoints for actually passing media.
On 23/05/07, Alex Balashov [EMAIL PROTECTED] wrote:
Gavin,
Hi.
Does the Asterisk server's route to 192.168.45.183 traverse a firewall or
router that may be blocking non-SIP ports that are dynamically allocated?
Nope, all internal.
SDP -- part of the SIP INVITE transaction
Does the non-Asterisk server _answer_ the line? :)
Gavin Henry wrote:
Dear All,
I have a tiny dial plan like:
[testing]
exten = 454,s,Ringing()
exten = 454,n,Wait(4)
exten = 454,n,Dial(SIP/[EMAIL PROTECTED]:5605,10)
exten = 454,n,Hangup
This connects fine when I dial 454 from any extension
The 2 most common problems I've seen for no audio in one or both
directions is usually either a firewall (which you already said you don't
have) or a CODEC problem.
Make sure both sides are negotiating the same CODEC. I've often seen
situations where something like the Asterisk server will
