Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Problem with setting up AES

Dear All Experts

I run in to troble with external stand alone VC  try to call in with encryption on.

I have set up tandberg mxp 1700 register the H.323  and SIP to my VCSC and  VCSE

When I try to make a H323/SIP call from mxp 1700 to the external VC it work just fine

But when I try try to make a call from the external stand alone VC to mxp 1700.

It just disconnect by itself.

I looked it in to the lock . It just rejected by the vcse by the following log:

tvcs: Event="

Call Rejected

" Service="

H323

" Src-ip="

101.78.153.150

" Src-port="

11039

" Src-alias-type="

H323

" Src-alias="

MXP206

" Src-alias-type="

E164

" Src-alias="

852206

" Dst-alias-type="

H323

" Dst-alias="

mxp208@nete2mg.com

" Call-serial-number="

d14cee2e-ac58-11e1-84e0-0010f31ae488

" Tag="

d14cef0a-ac58-11e1-8f10-0010f31ae488

" Protocol="

TCP

" Response-code="

Undefined reason

" Level="

1

" UTCTime="

2012-06-02 02:15:30,854

"

everythin work out find with both system without enabel the encryption

my vcse version is x6.1

Any experts can me out on this?

Thanks

Everyone's tags (3)
17 REPLIES
Cisco Employee

Problem with setting up AES

Do you have firewall between VCS Expressway and external standalone T1700 MXP Endpoint?

Assume call will disconnect approximate in 15~17 seconds.

For H323 encryption call, hash key for encryption negotiation includes in Q.931 setup message which some of firewall (especially firewall run with old software and enable H.323 ALG feature) won’t understand (or reject) as H.323 signal.

To isolate firewall possibility, you may try following test all:

- Let external standalone T1700MXP to register on VCS Expressway and make an encryption call (isolating the firewall issue on T1700MXP side, if any)

- Let other external standalone H323 Endpoint to call in to your Endpoint under VCS Expressway (other H323 Endpoint in different network to isolating the firewall issue on VCS Expressway side, if any)

To diagnose this issue further we would need to collect a diagnostics log from your VCS Expressway (if call is H.323-H.323 call then “debug” level logging on network log from diagnostic logging page under maintenance) and I would therefore recommend you raise a case with TAC to get this further looked into.

New Member

Problem with setting up AES

Thank for your help Tomonori !

In my case, the call disconnect immediately.

I will try to look in to the firewall and try your test case.

THX

Cisco Employee

Problem with setting up AES

Oh sorry, yes if issue with call negotiation (i.e. firewall deny some of negotiation packet), call may drop immediately or within few seconds.

I mixed up with media channel negotiation issue. FYI, if call negotiation success but failed to open media channel (for H323 call), then call will terminate approximate in 17 seconds (Endpoint initiate the call termination after timeout for waiting active media channel).

New Member

Problem with setting up AES

Thx Tomonori

I will try to look in to my firewall.

New Member

Re: Problem with setting up AES

Hi Tomonori

Sorry to bother you again.

Right now the H323 with encryption call is working fine:

But the SIP with encryption call only able to working on the following:

1) making call from internal to internal

2) making call from internal to external

The problem is when making call from external to interal, the call is connected successfully but both End points have a message of "Waiting for encryption on other side".

What could be wrong?

If I set the encryption off , the SIP call just work fine with the following:

1) making call from internal to internal

2) making call from internal to external

3) making call from external to internal

Cisco Employee

Problem with setting up AES

What is model and version of  SIP UA on external?

Do both SIP UAs enable SIP and negotiating call with TLS?

I’d suggest taking diagnostic log from VCS and verified both SIP UAs negotiate the call with crypto capability in SDP.

How does external SIP UA dialing to internal SIP UA make a call, URL with SRV record?

If so, is your SRV record has TLS record as highest priority?

Possibly external SIP UA initiate the SIP call with TCP not TLS.

New Member

Problem with setting up AES

The external device is a standard alone MXP 1700(without register to SIP proxy).

The external VC is using URL to dail in into the internal SIP UA.

Here is the log when the call is connected.

tvcs: Event="

Call Connected

" Service="

SIP

" Src-ip="

101.78.153.150

" Src-port="

5061

" Src-alias-type="

SIP

" Src-alias="

sip:101.78.153.150

" Dst-alias-type="

SIP

" Dst-alias="

sip:mxp208S@nete2mg.com

" Call-serial-number="

4e8e1020-b375-11e1-bf30-0010f31ae488

" Tag="

4e8e10fc-b375-11e1-b3f0-0010f31ae488

" Protocol="

TLS

" Call-routed="

YES

" Level="

1

" UTCTime="

2012-06-11 03:27:04,973

"

The protocol is connected by "TLS"

All the endpoint's "Transport" for internal and external are set to "TLS"

and the "TLS" are set to "ON" for VCS-C and VCS-E.

I will take a look on my SRV record

THX

Cisco Employee

Problem with setting up AES

> The external device is a standard alone MXP 1700(without register to SIP proxy).

Please note MXP Endpoint without register SIP proxy is not officially supported method by Cisco to make a SIP call (although it works).

SIP UA (MXP Endpoint) should register on SIP proxy when making an SIP call.

New Member

Problem with setting up AES

Thanks Tomonori.

Cisco Employee

Problem with setting up AES

BTW, as far as I confirm, SRV for your domain only have record of TCP and UDP but not TLS.

For TLS, SRV format will be _sips._tcp.domain.com. with port 5061.

New Member

Problem with setting up AES

Thanks Tomonir

I do have a TLS SRV with port 5061 for internal (vcs-c) and external (vcs-e).

and the priority is set to 1.

already open port 5060 on my firewall.

I caputer the log on my MXP 1700 endpoint:

netaddr_to_sockaddr: Invalid NET_ADDR type: -1

TTNET_sendto: Unable to convert netaddr to sockaddr

socklib_processSendReq: SendTo error on sock RtpStack/2/75/29 : -21, occured 16 times: Invalid semaphore

netaddr_to_sockaddr: Invalid NET_ADDR type: -1

TTNET_sendto: Unable to convert netaddr to sockaddr

socklib_processSendReq: SendTo error on sock RtpStack/2/74/28 : -21, occured 4 times: Invalid semaphore

netaddr_to_sockaddr: Invalid NET_ADDR type: -1

TTNET_sendto: Unable to convert netaddr to sockaddr

netaddr_to_sockaddr: Invalid NET_ADDR type: -1

TTNET_sendto: Unable to convert netaddr to sockaddr

7.1: SipTrnsp(nn=1,tid=18) Altering parameters of Contact header

netaddr_to_sockaddr: Invalid NET_ADDR type: -1

TTNET_sendto: Unable to convert netaddr to sockaddr

Would this be cause of the problem.

Thanks for your help Tomonori, Really a appreciate

Cisco Employee

Re: Problem with setting up AES

Unfortunately above logs doesn't give us much idea what actually causing one-way-video while TLS is used and specific call direction.

Please note that log from Endpoint and VCS will contain private information (especially device on public network), I'd suggest to open case with TAC for further investigation, if necessary (please careful with posting any logs on this community site).

New Member

Problem with setting up AES

Thanks for reminding for posting log issue. I will open a case with TAC.

Really appreciate for your help!

Cisco Employee

Problem with setting up AES

Thanks.

The “syslog” from both internal and external Endpoint (“syslog on” to start logging and “syslog off” to stop logging) and “debug” level diagnostic log from VCS together with configuration of devices will help TAC to look into your case quickly.

New Member

Problem with setting up AES

THX! Also one more question.

now I am focusing to work on Traverl zone and local zone only

Is other zone have a anything to do with my case.

Since the SIP call withount encryption is working fine.

Cisco Employee

Problem with setting up AES

Default Subzone and Default Zone will involve traversal call/registration in default configuration.

However current release version doesn’t have any configuration that will control enable/disable encryption over SIP call while using TLS as transport protocol.

So as long as TLS is in used for your call, your zone configuration should be fine.

Please note that there are few firewalls does support TLS inspection today (Cisco ASA, Checkpoint, etc.). If you are using such firewall, I’d suggest to disable it for isolating firewall issue. (please note very unfortunately some of firewall may require create rule manually to disable TLS inspection even it have check box to disable the TLS inspection…).

New Member

Problem with setting up AES

Thanks Tomonori

I am using Cisco ASA5510 firewall. It should be suitable for our case.

I will try to disable thel TLS inspection

THX for your help

1861
Views
0
Helpful
17
Replies