Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
6398
Views
1
Helpful
7
Replies

VCS-Expressway outbound dialing issues

Hermanus Janse van Vuuren
Level 5
Level 5

‎04-29-2013 01:43 AM - edited ‎03-18-2019 01:01 AM

Hi,

I hope someone can just point me in the right direction here.

I have a VCS-E ---- F/W ----- Internet

I can make a succesfull H.323 call to another IP out on the internet.

But when I make a SIP call it fails under the call history it shows as leaving my VCS-E and F/W as SIP and returns as H.323 and gives me the error 480 Temorary Unavailible.

How do I get my VCS-E to send the calls as SIP and receive it back as a SIP call.

My VCS-E has a 1 to 1 NAT to a public IP on the F/W.

What am I doing wrong?

2013-04-29 10:15:082013-04-29 10:15:091 secondsip:5000@example.comsip:ny.publicspy.tsec@cisco.comTraversalSIP <-> H323480 Temporarily Not AvailableThis systemView

Call details

You are here: Status Calls Calls Call details

Call information
StateConnection Failed
Start time2013-04-29 10:15:08
End time2013-04-29 10:15:09
Duration1 second
Tage7ca80ac-b0a4-11e2-a57a-0010f325e27c
Serial numbere7ca7ef4-b0a4-11e2-a0ea-0010f325e27c
Bandwidth
Requested768 kbps
Allocated0 kbps
Leg 1
Bandwidth nodeDefault Subzone
Source alias 1sip:5000@example.com (Url)
Target alias 1sip:ny.publicspy.tsec@cisco.com (Url)
ProtocolSIP
Addressxxx.xxx.xxx.xxx:5061
TransportTLS
ReasonTemporarily Not Available
Cause480
Leg 2
Bandwidth nodeCisco
Target alias 1sip:ny.publicspy.tsec@cisco.com (Url)
ProtocolSIP
Address64.102.249.41:5061
TransportTLS
Encryption typeNone
Leg 3
Bandwidth nodeCisco
Target alias 1(Unknown)
ProtocolSIP
AddressNot set
TransportSIP Transport Protocol Undefined
Leg 4
Bandwidth nodeDNSZone
Target alias 1sip:ny.publicspy.tsec@cisco.com (Url)
ProtocolSIP
Address64.102.249.41:5061
TransportTLS
Encryption typeNone
Leg 5
Bandwidth nodeDNSZone
Target alias 1sip:ny.publicspy.tsec@cisco.com (Url)
ProtocolSIP
Address64.102.249.41:5060
TransportTCP
Encryption typeNone
Leg 6
Bandwidth nodeDNSZone
Target alias 1ny.publicspy.tsec@cisco.com (Url)
ProtocolH323
Address64.102.249.41:1720
Encryption typeNone
ReasonUnreachable destination
CauseNo route to destination
Session 1
StatusFailed
Media routedFalse
Call routedTrue
Participant 1Leg 1
Participant 2Leg 2
Bandwidth allocated0 kbps
Bandwidth requested768 kbps
Session 2
StatusFailed
Media routedFalse
Call routedTrue
Participant 1Leg 1
Participant 2Leg 4
Bandwidth allocated768 kbps
Bandwidth requested768 kbps
RouteDefaultSubZone -> DefaultSZtoDNSZ -> DNSZone
Session 3
StatusFailed
Media routedFalse
Call routedTrue
Participant 1Leg 1
Participant 2Leg 5
Bandwidth allocated768 kbps
Bandwidth requested768 kbps
RouteDefaultSubZone -> DefaultSZtoDNSZ -> DNSZone
Session 4
StatusFailed
Media routedTrue
Call routedTrue
Participant 1Leg 1
Participant 2Leg 6
Bandwidth allocated682 kbps
Bandwidth requested682 kbps

Search Rule:

  • Search (4)
  • State: Completed
  • Found: False
  • Reason: Temporarily Not Available
  • Info: Bandwidth allocation failed
  • Type: SIP (INVITE)
  • CallSerial Number: e7ca7ef4-b0a4-11e2-a0ea-0010f325e27c
  • Tag: e7ca80ac-b0a4-11e2-a57a-0010f325e27c
  • Source (1)
    • Authenticated: False

    • Zone (1)
      • Name: DefaultSubZone
      • Type: Local
    • Path (1)
      • Hop (1)
        • Address: xxx.xxx.xxx.xxx:5061

  • StartTime: 2013-04-29 10:15:08
  • Duration: 1.36
  • SubSearch (1)
    • Type: Transforms
    • Action: Not Transformed
    • SubSearch (1)
      • Type: Admin Policy
      • Action: Proxy
      • SubSearch (1)
        • Type: FindMe
        • Action: Proxy
        • SubSearch (1)
          • Type: Search Rules
          • SearchRule (1)
            • Name: LocalZoneMatch
            • Zone (1)
              • Name: LocalZone
              • Type: Local
              • Protocol: SIP
              • Found: False
              • Reason: Not Found
              • StartTime: 2013-04-29 10:15:08
              • Duration: 0
            • Zone (2)
              • Name: LocalZone
              • Type: Local
              • Protocol: H323
              • Found: False
              • Reason: Not Found
              • StartTime: 2013-04-29 10:15:08
              • Duration: 0
          • SearchRule (2)
            • Name: Cisco
            • Zone (1)
              • Name: Cisco
              • Type: DNS
              • Protocol: SIP
              • Found: False
              • Reason: Temporarily Not Available
              • StartTime: 2013-04-29 10:15:08
              • Duration: 0.31
            • Zone (2)
              • Name: Cisco
              • Type: DNS
              • Protocol: H323
              • Found: False
              • Reason: Resource unavailable - No route for bandwidth calculation
              • StartTime: 2013-04-29 10:15:08
              • Duration: 0.01
          • SearchRule (3)
            • Name: DNS zone search rule
            • Zone (1)
              • Name: DNSZone
              • Type: DNS

              • Protocol: SIP
              • Found: False
              • Reason: Request Timeout
              • StartTime: 2013-04-29 10:15:08
              • Duration: 0.02
            • Zone (2)
              • Name: DNSZone
              • Type: DNS
              • Protocol: H323
              • Found: True
              • StartTime: 2013-04-29 10:15:08
              • Duration: 0.95
    Best Regards
    Labels:
    0 Helpful
    7 Replies 7

    Martin Koch
    VIP Alumni
    VIP Alumni

    ‎04-29-2013 02:19 AM

    Hi Janse!

    It might be different things here which can cause issues.

    First, if you have 1:1 nat upfront the VCS-E you need to have the "Dual interface" option key, even

    if you use only one interface, but that option also gives you a setting where you can define the

    outside NAT ip on the VCS.

    You also need to take care if you are using a NATed interface that all communication is done

    towards that external IP, if you require communication with an internal ip or clustering you would need

    the secondary interface as well.

    There are some more postings regards this topic in the forum, please search for it.

    If you do not have the key, thats the first thing to fix as this is a main requirement!

    If its in place:

    Check that there are no ALG/Inspection/NAT helper or other SIP/H323 Layer3 features enabled

    on your firewall, that might lock something up.

    I tried the address mysef, and that might be a bad address to check on external sip communication,

    it seems that cisco address is only reachable via h323:

     |SIP/2.0 404 Not Found
     Via: SIP/2.0/TLS xxx;egress-zone=DNS;xxx
     Via: SIP/2.0/TLS xxx
     Call-ID: xxx@192.168.101.62
     CSeq: 100 INVITE
     From: xxx
     To: <>ny.publicspy.tsec@cisco.com>;tag=xxx
     Server: TANDBERG/4120 (X7.2.1)
     Warning: 399 64.103.25.133:5061 "Policy Response"
     Content-Length: 0

    But at least an interworked call should work from your sip client.

    Not sure how your sip settings are, I noticed I did not get encrypted media towards the remote site,

    depending on your settings (force encryption) that can also cause issues.

    Please rate the postings via the stars below and set the thread to answered if it is!

    Please remember to rate helpful responses and identify

    0 Helpful

    Hermanus Janse van Vuuren
    Level 5
    Level 5
    In response to Martin Koch

    ‎04-29-2013 03:01 AM

    Managed to make the call out using the following URI.

    I ahve the dual network card option key everything, it seems like some sort of DNS or SRV record issue maybe for the return path???

    sip:ny.publicspy.tsec@64.102.249.41 (Url)

    • Search (20)
    • State: Completed
    • Found: True
    • Type: SIP (INVITE)
    • CallRouted: True
    • CallSerial Number: bb85a632-b0ab-11e2-9329-0010f325e27c
    • Tag: bb85a7f4-b0ab-11e2-8f09-0010f325e27c
      • Source (1)
        • Authenticated: False
        • Zone (1)
          • Name: DefaultSubZone
          • Type: Local
        • Path (1)
          • Hop (1)
            • Address: xxx.xxx.xxx.xxx:5060

      • Destination (1)
        • Alias (1)
          • Type: Url
          • Origin: Unknown
          • Value: sip:ny.publicspy.tsec@64.102.249.41
      • StartTime: 2013-04-29 11:04:00
      • Duration: 1.11
      • SubSearch (1)
        • Type: Transforms
        • Action: Not Transformed
        • ResultAlias (1)
          • Type: Url
          • Origin: Unknown
          • Value: ny.publicspy.tsec@64.102.249.41
        • SubSearch (1)
          • Type: Admin Policy
          • Action: Proxy
          • ResultAlias (1)
            • Type: Url
            • Origin: Unknown
            • Value: ny.publicspy.tsec@64.102.249.41
          • SubSearch (1)
            • Type: FindMe
            • Action: Proxy
            • ResultAlias (1)
              • Type: Url
              • Origin: Unknown
              • Value: ny.publicspy.tsec@64.102.249.41
            • SubSearch (1)
              • Type: Search Rules
              • SearchRule (1)
                • Name: LocalZoneMatch
                • Zone (1)
                  • Name: LocalZone
                  • Type: Local
                  • Protocol: SIP
                  • Found: False
                  • Reason: Not Found
                  • StartTime: 2013-04-29 11:04:00
                  • Duration: 0
                  • Gatekeeper (1)
                    • Address: 172.20.4.241:0
                    • Alias (1)
                      • Type: Url
                      • Origin: Unknown
                      • Value: ny.publicspy.tsec@64.102.249.41
                • Zone (2)
                  • Name: LocalZone
                  • Type: Local
                  • Protocol: H323
                  • Found: False
                  • Reason: Not Found
                  • StartTime: 2013-04-29 11:04:00
                  • Duration: 0
                  • Gatekeeper (1)
                    • Address: xxx.xxx.xxx.xxx:0

                    • Alias (1)
                      • Type: Url
                      • Origin: Unknown
                      • Value: ny.publicspy.tsec@64.102.249.41

              • SearchRule (2)
                • Name: DNS zone search rule
                • Zone (1)
                  • Name: DNSZone
                  • Type: DNS
                  • Protocol: SIP
                  • Found: True
                  • StartTime: 2013-04-29 11:04:00
                  • Duration: 1.04
                  • Gatekeeper (1)
                    • Alias (1)
                      • Type: Url
                      • Origin: Unknown
                      • Value: ny.publicspy.tsec@64.102.249.41

        Best Regards
        0 Helpful

        Martin Koch
        VIP Alumni
        VIP Alumni
        In response to Hermanus Janse van Vuuren

        ‎04-29-2013 02:53 PM

        Did you factory default the VCS reacently?

        Do you have all the needed defautl links?

        Logging in as admin via ssh/console and execute:

        xcommand DefaultLinksAdd

        might be worth giving a try.

        Besies that, did you check with the dns lookup tool that your DNS is getting properly resolved?

        Also do not forget to check the firewall and your vcs and router nat setup

        Janse: Please rate the postings!

        Please remember to rate helpful responses and identify

        0 Helpful

        Hermanus Janse van Vuuren
        Level 5
        Level 5
        In response to Martin Koch

        ‎04-29-2013 10:49 PM

        No Factory reset reacently was configured out of the box.

        I have all the dafault links plus the ones I have added.

        xcommand DefaultLinksAdd

        *r Result (status=OK): /
        *r/end

        OK

        DNS Lookup works if I do it for cisco.com but not for the full URI.

        Acisco.com.10618INA72.163.4.161
        AAAAcisco.com.86400INAAAA2001:420:1101:1::a
        SRV_h323ls._udp.cisco.com.8030INSRV1 0 1719 vcsgw.cisco.com.
        SRV_h323cs._tcp.cisco.com.86400INSRV1 0 1720 vcsgw.cisco.com.
        SRV_sips._tcp.cisco.com.8030INSRV1 0 5061 vcsgw.cisco.com.
        SRV_sip._tcp.cisco.com.8029INSRV1 0 5060 vcsgw.cisco.com.

        On my firewall I see the calls leave as SIP and comes back as H.323 for some reason when dialing the full URI.

        But dialing the URI with the @xxx.xxx.xxx.xxx that I get from my call history when trying to resolve the full URI it works like a charm.

        I will be moving the VCS-E to a DMZ zone later when the network is upgraded and ready but for testing and demo purposes I need to get it working with a 1:1 NAT using one LAN port on the VCS-E. So when the VCS-E moves to the DMZ I will bring up my VCS-C again as well.

        Best Regards
        0 Helpful

        sagsheth
        Cisco Employee
        Cisco Employee
        In response to Hermanus Janse van Vuuren

        ‎04-30-2013 02:56 AM

        Hi Janse,

        Have you tried to resolve DNS from VCS-E? if not please check if VCS-E has correct DNS server and is able to resolve SRV records for cisco.com.

        Please see the snippet.

        • SearchRule (3)
          • Name: DNS zone search rule
          • Zone (1)
            • Name: DNSZone
            • Type: DNS
            • Protocol: SIP
            • Found: False
            • Reason: Request Timeout
            • StartTime: 2013-04-29 10:15:08
            • Duration: 0.02

        Here Request times out, so call is sent out as H323.

        Let me know if you have any queries.

        Regards,

        Sagar

        0 Helpful

        Hermanus Janse van Vuuren
        Level 5
        Level 5
        In response to sagsheth

        ‎04-30-2013 06:42 AM

        I am moving my VCS-E to a DMZ zone next week with a public IP getting away from the NAT situation, will test next week and give feedback thank you.

        Best Regards
        0 Helpful

        Mark Turpin
        Level 5
        Level 5

        ‎12-08-2014 12:15 PM

        I really hate to comment on such an old thread...

        But I had a similar issue with a similar problem.  I found that in my case, this was resolved by using TCP instead of TLS.  When I changed my endpoints to use TCP, the ASA inspecting the SIP traffic and offering the NAT conversion for me was able to see the traffic and change the IP's correctly.  Calls worked fine after that point.

        --
        -Mark Turpin
        Customers Also Viewed These Support Documents