Andrew Stewart wrote:
Figured out the problem. There is an inspect sip command in our
global policy map on our Cisco ASA firewall. That was fixing the
CALL-ID. Took it out and all is working now.
Ah, yes. Those ALGs (or other = Layer 5 manglers, whatever the
justification) will always
10 sep 2009 kl. 17.35 skrev Alex Balashov:
Andrew Stewart wrote:
Figured out the problem. There is an inspect sip command in our
global policy map on our Cisco ASA firewall. That was fixing the
CALL-ID. Took it out and all is working now.
Ah, yes. Those ALGs (or other = Layer 5
On Thu, Sep 10, 2009 at 12:51 PM, Olle E. Johansson o...@edvina.net wrote:
You were lucky that you could disable it. I've met cases where
firewalls have a smart SIP something feature that can't be disabled
and enabled it was successful in disabling all media stream by
publishing RFC1918
We are using using what Cisco's Port Address Translation, so that all
SIP traffic is done through %EXTERNIP%. To any outside box, it should
look like the asterisk server is actually on %EXTERNIP%.
My SIP packet gets sent to the ITSP with a Call-ID:
2fd557964ca936b1d72f1328c...@%externip% ,
Andrew Stewart wrote:
We are using using what Cisco's Port Address Translation, so that all
SIP traffic is done through %EXTERNIP%. To any outside box, it should
look like the asterisk server is actually on %EXTERNIP%.
My SIP packet gets sent to the ITSP with a Call-ID:
On Wed, Sep 9, 2009 at 8:59 AM, Alex Balashovabalas...@evaristesys.com wrote:
Andrew Stewart wrote:
We are using using what Cisco's Port Address Translation, so that all
SIP traffic is done through %EXTERNIP%. To any outside box, it should
look like the asterisk server is actually on
On Wed, Sep 9, 2009 at 10:45 AM, Andrew Stewart astew...@notre1.com wrote:
On Wed, Sep 9, 2009 at 8:59 AM, Alex Balashovabalas...@evaristesys.com
wrote:
Andrew Stewart wrote:
We are using using what Cisco's Port Address Translation, so that all
SIP traffic is done through %EXTERNIP%. To
