cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9679
Views
5
Helpful
13
Replies

Traversal Call Issue - 403 Forbidden

Hi,

We have deployed VCS Control with VCS Expressway for firewall traversal and encountered  issue. On the VCSe call status, it says 403 forbidden

when an external endpoint registered as SIP on the VCSe will initiate a call to an internal endpoint registered as SIP to VCSc.

Here are some of the test scenarios we conducted and results:

1. Internal endpoints SIP registration to VCSc - OK

2. External endpoint SIP registartion to VCSe - OK

3. Internal endpoint  to internal endpoint SIP calls via VCSc - OK

4. External endpoint  to external endpoint SIP calls via VCSe - OK

5. Internal endpoint to external endpoint SIP call via VCSc and VCSe - OK

6. External endpoint to internal endpoint SIP call via VCSc and VCSe - Failed (403 forbidden)

On item 6, that's the only problem we are trying to resolve.

What are needed to check?

Thank you.

Br,

Acevirgil de Ocampo

1 Accepted Solution

Accepted Solutions

I definitely recommend creating a subzone for Movi, as you can also control bandwidth also. I never register anything to the default subzone on the Expressway and disable registration for security purposes. Movi clients register to their own subzone

nes along with subzones for other specific things.

For security sake, I don't like not checking for credentials on the Expressway, especially if you have a ISDN gateway or perhaps the Control has a route out to the PSTN. Toll fraud is not sweet.

I always have deployed SSO via LDAP vs local authentication. It gets tricky when you can't join the Expressway to the domain but still want to authenticate and check credentials. The trick is you need to create a local user on Expressway, then actually create the same identical username and password in active directory. Then in TMS, push out these credentials using the configuration template for the version / device of MOVI.

View solution in original post

13 Replies 13

Patrick Sparkman
VIP Alumni
VIP Alumni

What are the endpoints?

Can you show us the search history on the VCS that is giving you the error?

Is it SIP all the way though?

Any transforms taking place?

Hi Patrick,

We are using a TANDBERG 1700 MXP as external endpoint registerd as SIP on VCSe and C40 endpoint registered on VCSc.
Both VCS are running X7.2.2.
All calls were pure SIP. No H323 and interworking involved.

Here are some of the event logs from VCSe:

2014-02-19T00:29:18+08:00 tvcs: Event="Call Rejected" Service="SIP" Src-ip="122.x.x.x" Src-port="5061" Src-alias-type="SIP" Src-alias="sip:4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Detail="Forbidden" Protocol="TLS" Response-code="403" Level="1" UTCTime="2014-02-18 16:29:18,463"
2014-02-19T00:29:18+08:00 tvcs: Event="Search Completed" Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Detail="found:false, searchtype:INVITE" Level="1" UTCTime="2014-02-18 16:29:18,463"
2014-02-19T00:29:18+08:00 tvcs: Event="Call Attempted" Service="SIP" Src-ip="122.x.x.x" Src-port="5061" Src-alias-type="SIP" Src-alias="sip:4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Protocol="TLS" Auth="NO" Level="1" UTCTime="2014-02-18 16:29:18,433"
2014-02-19T00:29:18+08:00 tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="4995@sample.com" Dst-alias-type="SIP" Dst-alias="sip:4980@sample.com" Call-serial-number="d06b2e4a-98b9-11e3-b991-0010f32d03e4" Tag="d06b2fee-98b9-11e3-a905-0010f32d03e4" Detail="searchtype:INVITE" Level="1" UTCTime="2014-02-18 16:29:18,433"

I configured one transform on the VCSe: Transform destination aliases to URI format

Pattern type: regex

Pattern string: ([^@]*)

Pattern behavior: replace

Replace string: \1@sample.com

Thanks,

Acevirgil

Thanks.

On the VCS that shows the error, goto Status > Search History, and find a failed search and paste that.  From there we can see what is being applied and done to the call.

Hi Patrick,

here's the search history for the call:

Search (11)

State: Completed

Found: False

Reason: Forbidden

Type: SIP (INVITE)

CallSerial Number: f91c9c16-98be-11e3-a8c1-0010f32d03e4

Tag: f91c9dc4-98be-11e3-9950-0010f32d03e4

Source (1)

Authenticated: False

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: 4995@sample.com

Zone (1)

Name: DefaultSubZone

Type: Local

Path (1)

Hop (1)

Address: 122.x.x.x:5061

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:4980@sample.com

StartTime: 2014-02-19 01:06:14

Duration: 0.04

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: 4980@sample.com

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: 4980@sample.com

SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: 4980@sample.com

SubSearch (1)

Type: Search Rules

SearchRule (1)

Name: Local zone – no domain

Zone (1)

Name: LocalZone

Type: Local

Protocol: SIP

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: E164

Origin: Unknown

Value: 4980

Zone (2)

Name: LocalZone

Type: Local

Protocol: H323

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: E164

Origin: Unknown

Value: 4980

SearchRule (2)

Name: Local zone – full URI

Zone (1)

Name: LocalZone

Type: Local

Protocol: SIP

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: Url

Origin: Unknown

Value: 4980@sample.com

Zone (2)

Name: LocalZone

Type: Local

Protocol: H323

Found: False

Reason: Not Found

StartTime: 2014-02-19 01:06:14

Duration: 0

Gatekeeper (1)

Address: 112.x.x.x:0

Alias (1)

Type: Url

Origin: Unknown

Value: 4980@sample.com

SearchRule (3)

Name: Traversal zone search rule

Zone (1)

Name: Traversal Zone

Type: TraversalServer

Protocol: SIP

Found: False

Reason: Forbidden

StartTime: 2014-02-19 01:06:14

Duration: 0.03

Gatekeeper (1)

Address: 10.x.x.x:28364

Alias (1)

Type: Url

Origin: Unknown

Value: 4980@sample.com

Thank you for your help.

Acevirgil

Patrick Sparkman
VIP Alumni
VIP Alumni

Paste the search history from the other VCS that it's trying to traverse to for this call. Also, what is the authentication policy set for the traversal zone on the Control?

Sent from Cisco Technical Support iPhone App

Hi Patrick,

On the Traversal zone on both VCS, I changed the authentication policy from "Check credentials" to "Do not check credentials" and now it works.

Issue was resolved but our problem is we cannot login on the VCS Expressway using Jabber client. Internal jabber can successfully login on the VCS control.

Right now the VCS servers athentication policy were configured this way:

VCS Control:

Default subzone: check credential

Default zone: check credential

Traversal zone: do not check credential

VCS Expressway:

Default subzone: check credential

Default zone: check credential

Traversal zone: do not check credential

What should be the proper configurations of the authentication policy on each zones on bothe VCS?

All authentication were authenticated on the VCS local database.

Thank you.

Br,

Acevirgil

Glad you got it figured out, I had a similar instance not too long ago testing authentication methods. The Control should be set to check, while the Expressway should be do not check. The provisioning deployment guide can help in setting up the Control and Expressway zones for authentication.

Sent from Cisco Technical Support iPhone App

Hi Patrick,

On the VCS Control:

Default subzone: check credential

Default zone: check credential

Traversal zone: check credential

On the VCS Control:

Default subzone: do check credential

Default zone: do check credential

Traversal zone: do not check credential

The Jabber on the extenal can login again but our previous problem encounterd again.

Thanks,

Acevirgil

Are you trying to authenticate to the Control or Expressway. Typically, authentication would be proxied to the Control and done there. Are there any sub zones in place for the Jabber Video users?

Sent from Cisco Technical Support iPhone App

Hi Patrick,

All authentication should be on the VCS Control. No zubzones yet for Jabber users.

Do we need to create subzones for jabber users on the Control or in Expressway?

Thanks,

Acevirgil

The subzone comment was just trying to find out if maybe if you had any, those authentication settings would also affect how a Jabber Video user logs in.

In our environment, the Expressway is set to do not check for all zones, the Control is set to Check for all zones.  Which include the Default Subzone, Traversal Zone, etc.  Do you have the SIP domain configured on the Expressway?  I'm running out ideas, maybe someone else might have something in mind, I'd run through the provisioning deployment guide to try and double check all of the configurations.

I definitely recommend creating a subzone for Movi, as you can also control bandwidth also. I never register anything to the default subzone on the Expressway and disable registration for security purposes. Movi clients register to their own subzone

nes along with subzones for other specific things.

For security sake, I don't like not checking for credentials on the Expressway, especially if you have a ISDN gateway or perhaps the Control has a route out to the PSTN. Toll fraud is not sweet.

I always have deployed SSO via LDAP vs local authentication. It gets tricky when you can't join the Expressway to the domain but still want to authenticate and check credentials. The trick is you need to create a local user on Expressway, then actually create the same identical username and password in active directory. Then in TMS, push out these credentials using the configuration template for the version / device of MOVI.

Hi Daniel,

Thank you for some inputs and recommendations.

Default Zones, subzones authentication policy on both VCS are set to "Check credentials" except for Traversal zone set as "do not check credentials/treat as authenticated" on the servers.

Yeah, your right. In our case, we used to create authentication database for Jabber users on the VCSe identical with the credentials made on TMS provisioning and works fine now. Eventually we will be integrating the VCS servers with AD for centralized authentication and more secure environment.

Thank you.

Br,

Acevirgil

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: