Problem with setting up AES

[chanhontung]

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

[Tomonori Taniguchi]

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.

[chanhontung]

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

[Tomonori Taniguchi]

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).

[chanhontung]

Thx Tomonori

I will try to look in to my firewall.

[chanhontung]

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

[Tomonori Taniguchi]

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.

[chanhontung]

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

[Tomonori Taniguchi]

> 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.

[chanhontung]

Thanks Tomonori.

[Tomonori Taniguchi]

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.

[chanhontung]

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

[Tomonori Taniguchi]

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).

[chanhontung]

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

Really appreciate for your help!

[Tomonori Taniguchi]

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.