cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3882
Views
0
Helpful
8
Replies

VCSE - Not accepting pre-loaded route headers?

johan.alkarp
Level 1
Level 1

Hi all,

Setting up a VCSC-VCSE and able to dial out and internal between EPs. But when a external EP is trying to call in i recieve this in search history logs for calls.

Search (177)

State: Completed

Found: False

Reason: Not Found

Info: Policy Response

Type: SIP (INVITE)

CallSerial Number: 45d4b6f4-5be6-11e2-90a0-0010f3237c5e

Tag: 45d4b8a2-5be6-11e2-be33-0010f3237c5e

Source (1)

Authenticated: True

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: e20.sip@xx.xxx

Zone (1)

Name: DefaultSubZone

Type: Local

Path (1)

Hop (1)

Address: 192.x.x.x:5061

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:ex90.sip@xx.xxx

StartTime: 2013-01-11 12:58:54

Duration: 0

SubSearch (1)

Type: Directed

Found: False

Reason: Not accepting pre-loaded route headers

Path (1)

Hop (1)

Address: 19x.x.x.x3

StartTime: 2013-01-11 12:58:54

Duration: 0

Just want to check if anyone seen this and knows what it's about?

// Johan

1 Accepted Solution

Accepted Solutions

awinter2
Level 7
Level 7

Hi Johan,

"Not accepting pre-loaded route headers" most likely 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. This can for example happen when a VCS-E is deployed behind a NAT without having the Dual Network Interfaces option key, or if a VCS is addressed by a DNS CNAME which is different from the configured hostname+domain name on the VCS.

Could you capture the incoming INVITE with a diagnostics log and check what route set this INVITE has?

View solution in original post

8 Replies 8

awinter2
Level 7
Level 7

Hi Johan,

"Not accepting pre-loaded route headers" most likely 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. This can for example happen when a VCS-E is deployed behind a NAT without having the Dual Network Interfaces option key, or if a VCS is addressed by a DNS CNAME which is different from the configured hostname+domain name on the VCS.

Could you capture the incoming INVITE with a diagnostics log and check what route set this INVITE has?

Thanks for a quick answer, will check those things and reply back.

// Johan

The search history entry implies that this call attempt came from a locally registered endpoint:

Source (1)

Authenticated: True

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: e20.sip@xx.xxx

Zone (1)

Name: DefaultSubZone

Type: Local

Path (1)

Hop (1)

Address: 192.x.x.x:5061

You should laso verify which VCS is generating the '404 Not Found' response, it might not be this one.

True, but we are recieving the same problem when recieving calls from external EPs.

The local reg EP was registered on the VCSE, trying to talk to a EP on the VCSC.

// Johan

I've looked through the invites and it does seem to be the NAT problem overwriting, so trying to figure out what would be the best way of solving this. NAT LIC or NAT reflect ( i think it was called)

Thanks for your help!

// Johan 

Johan,

so this VCS-E is behind a NAT of some sort? Does the VCS-E have the dual NIC option key installed, and if so, is static NAT configured on the VCS-E?

Your reply shows that you solved it ...what was the solution?

What was the solution to this?