SIP calls failing

[mark.hudson6365]

Hi,

I implemented VCSs in two sites, Site A and site B and I did the appropriate neighbouring between Site A and Site B VCSs. Search rules and transforms are configured and in place and working.

The calls from Site B to Site A (H323 and SIP) are working fine, but calls from Site A to Site B are only working for H323. The strange things here is the locate tools show the address is resolvable and true for this search nevertheless SIP calls from Site A to Site B are not working when the calls is initiated from an Cisco endpoint. I have already spent a few days and double checked everything but cannot crack this case, anyone knows what's wrong?

Thanks in advance. Mark

[ahmashar]

Hi Mark,

- Are firewall ports configured correctly for Site A?

- What version of VCSs are you using?

- What type of endpoints and software version are you running?

- Are VCSs standalone or cluster?

- Can you call any other SIP points in the internet other than SIP endpoint in Site B?

- if not, what error message do you get?

- Have you checked the log files (with DEBUG mode on) to see the call is actually going through the designated zones?

- Also How is the SIP call routed between VCSs in Site A and Site B? I mean is the neighbor zones between VCS controller or VCS expressway?

regards, Ahmad

[mark.hudson6365]

Ahmad,

Answers inline.

- Are firewall ports configured correctly for Site A? the rules and port opening were cloned from site B. So I believe ports are configured correctly.

- What version of VCSs are you using?   7.2

- What type of endpoints and software version are they running? EX90 and EX60 with TC6.1

- Are VCSs standalone or cluster? site A is standalone and Site B is clustered

- Can you call any other SIP points in the Internet other than SIP endpoint in Site B?  no, SIP calls doesn't go through.

- if not, what error message do you get? 404 Not Found

- Have you checked the log files (with DEBUG mode on) to see the call is actually going through the designated zones? yes. 404 not found message

- Also How is the SIP call routed between VCSs in Site A and Site B? I mean is the neighbor zones between VCS controller or VCS expressway? I have more sites in our network but between these two sites, the call is routed Site A through VCSE and Internet to the VCSE in to Site B

Mark

[Paulo Souza]

Hi Mark,

Let's assume that you have configured your dial plan and neighbor configuration properly, and let's assume you don't have any firewall issue. Please, make a call from site A to site B using SIP. Go to search history and see the lookup retaled to the call you made, please, post the call attempt here. Also, go to Status > Logs > Network Log and post here the output related to your call attempt. Please, take the logs from both VCS's, site A and site B. As you have cluster, be aware that the call history only appears in one peer of the cluster, the peer where by the call passed through.

Checking those logs we can point if there is a problem related to your dial, firewall or something else.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[mark.hudson6365]

Paulo,

Here is the history (replaced the actual addresses with siteA and B):

Search (15)

       State: Completed

       Found: False

       Reason: Not Found

       Info: Policy Response

       Type: SIP (INVITE)

       CallSerial Number: 847a1914-c351-12e2-91ae-00e0f781e9ae

       Tag: 848e2ab2-c451-11e2-a952-00e0f781e9ae

       Source (1)

            Authenticated: True

             Aliases (1)

                   Alias (1)

                   Type: Url

                    Origin: Unknown

                    Value: 1234@siteB.com

             Zone (1)

                   Name: DefaultSubZone

                    Type: Local

            Path (1)

                    Hop (1)

                    Address: 1.1.1.1:5061

       Destination (1)

             Alias (1)

                    Type: Url

                    Origin: Unknown

                    Value: sip:1234@siteB.com

       StartTime: 2013-07-16 17:18:06

       Duration: 0

       SubSearch (1)

             Type: Directed

             Found: False

             Reason: Not accepting pre-loaded route headers

             Path (1)

                    Hop (1)

                           Address: vc.siteA.com

            StartTime: 2013-07-16 17:18:06

             Duration: 0

Mark

[Paulo Souza]

Hi mark,

Was this output received in site A or site B? You made the call from site A, right?

Are your endpoints registering to VCS using hostname or IP address?  If they are registering using the hostname of VCS, have you configured the FQDN of VCS to match the hostname and domain created on DNS Server? Is there any inpsection/ALG feature enable on the firewall?

The message "Not accepting pre-loaded route headers" normally means that the incoming SIP INVITE contains a route set where the topmost route header does not match the VCS's IP address or configured FQDN. So you should check the hostname of VCS and FQDN configuration, as well as if there is any firewall inspection feature replacing SIP headers.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Paulo Souza]

Additionally, you can debug VCS signalling to capture the INVITE message received by the client, so you can check the invite message to see if the "route" field has the correct IP address or FQDN of your VCS.

For example, let's say you have made a call from site A to site B, and let's say the output you posted was taken from VCS located in site B. You could debug VCS-B to check the INVITE message received from site A. Into the SIP INVITE message, you can check if the "route" field has the correct IP address or FQDN of your VCS-B.

This is a piece of a SIP INVITE message:

SIPMSG:

|INVITE sip:21004021@doamin.com.br SIP/2.0

Via: SIP/2.0/TLS 10.10.10.254:55615;branch=z9hG4bK88956b172fb29ddb3274029694ff856c.1;received=189.189.189.189;rport=54102

Call-ID: d6bb358b83559385@10.0.0.254

CSeq: 101 INVITE

Contact: <>paulo@domain.com.br;gr=urn:uuid:717b950c-cae9-504c-8314-4c72ec2edb07>

From: "Paulo Souza" <>paulo@domain.com.br>;tag=38cea612cddb1937

To: <>21004021@domain.com.br>

Max-Forwards: 70

Route: <200.200.200.200:5061>

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY

User-Agent: TANDBERG/774 (MCX 4.6.3.17194) - Windows

Supported: replaces,100rel,timer,gruu

Session-Expires: 1800

Content-Type: application/sdp

Content-Length: 3090

Take a look at the red mark, this is the IP address of my VCS, if this address is incorrect, you can receive the message "Not accepting pre-loaded route headers". If this happens, maybe there is a firewall inpection/ALG problem that is replacing the IP address within SIP headers, or maybe you are sending the request to VCS using its hostname instead of IP address, but the hostname is wrong, or the hostname used does not match the FQDN configured in VCS.

To collect a INVITE message, you can use the page Status > Logs > Network Log. But in order to have a detailed log, first, you have to go to Maintenance > Diagnostics > Advanced > Network Log Configuration and set the option "network.sip" to DEBUG.

I hope those troubleshooting steps help you.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[ahmashar]

This thread

https://supportforums.cisco.com/thread/2192098

discusses the message of "Not accepting pre-loaded route headers" you are getting.

in addition to the points discussed in the thread:

- what are the authentication policy on defaultzone, DNS, Traversal zone, etc.?

- can you do internal SIP call (not via VCSE)?

- have you tried to use different endpoint other than EX90 and EX60 as you mentioned?

- is the external SIP endpoint reliable and sure it works?

- what do Debug log of VCSE and VCSC show?

regards, Ahmad

[mark.hudson6365]

Thanks guys for your support.

Paulo,
The call was from site A to Site B, so as said earlier no SIP Internet call from Site A - site B is fine. we are using VCS FQDN for registering to VCS. DNS is checked and configured correctly (it resolves to IP address of VCS). ALG is turned off and is cloned from site B and checked with other sites. I don't think firewall is the problem, our firewall admin has implemented the same rules as other sites and triple checked the rules and according to him there is no difference between the implemented rules for site A and site B, etc.
I am not going to post debug logs here for security reason and if I am going to change all the ip addresses then the logs get meaningless but what we can see as far as we understand there is no problem with the route.

Ahmad,
- the authentication is set to donotcheckcredential for those zones
- yes internal SIP calls fine
- this is interesting thing, I called SIP endpoint on site B using MCU and the call went through. So I just realized I can make a SIP Internet call via MCU but not EX-series. I don't have jabber client to test with yet.
- yes, the internet endpoint is reliable - it works from site B
- see above response.

Any more suggestion?

Mark 

[ahmashar · Accepted solution]

Hi Mark,

Since you are able to make SIP calls out to the internet via MCU and the zones are configured as donotcheckcredential, I would think the problem is with your endpoints rather than VCSs. Try this:

- check the DNS configuration on your endpoints (EX-series, etc) and make sure is correct and the connectivity is there

- make sure outbound parameter is set to off

- make sure the FQDN of VCSs are correct and not misspelled and resolvable

- if there is no proxy server between VCS and endpoints, make sure that field is empty.

- I don't think NTP server matters that much for SIP calls, nevertheless make sure NTP server is configured and working for the endpoints

- one more thing, try to register the endpoint which is already registered to site A to site B and try to make a SIP internet call, would it work?

regards,Ahmad

[mark.hudson6365]

Ahmad,

Thanks for your support. I set the outbound parameter off and the SIP call went through. It works now!!

I cannot believe such a simple parameter setting could create so much headache. I also unregistered the endpoint from site A and register it on site B and I could make SIP Internet calls (with the same settings, only thing was changed the VCS server addresses) but the same settings did not work for site A. The only difference I could see between the two sites apart from adjusting the search rules and FQDN VCS addresses, is site A is standalone and site B is cluster. we have other sites that are connected through the backbone and not through the Internet which never experienced such a problem before.

Much appreciated your help with this problem.

Mark

[ahmashar]

you are welcome. I am glad the problem is resolved.

One application of outbound parameter is to turn it “on” for  VCS cluster and turn it “off” for a single proxy server (i.e. VCS).

If your inquiry is answered, please rate and mark it as "Answered".

Thank you,

Ahmad

[Paulo Souza]

Hi Ahmad,

Really nice tip!! I guess nobody would imagine that he had configured this parameter to on, I would never imagine such thing.

5 starts!

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.