10-03-2014 01:20 AM - edited 03-18-2019 03:29 AM
Hi Team
we have created a collaboration edge sx20-cucm-expresswayC-expresswayE
The communication for now between EXPC and EXPE is tcp and not tls.We will install certificate at later on
Now Some questions:
1) i will install certificate from public ca into EXPE.And then what have to add(Certificates) between EXPC and EXPE to establish the tls connection?
2) I can call outside VCs from sx20 successfully but when i call from outside VC to sx20 through EXPE , the call going to sx20 and when i answer then the call drop.
Do you have any idea about the above?
/Chrysostomos
10-04-2014 02:20 PM
Chrys,
The transport protocol between expwe-e and c has to be TLS. The communication between the two has to be fully encrypted.
For the certificates, you need to install two certs on expwe and c..
1. The root CA certificate
2. Expwe and C certificates as server certs.
You need to generate CSR...
Generate CSR, send to CA to sign and use web and client server template
Upload cert as server certs.
Secondly on the issue you are having, it looks like you need to check your configuration. Looking at the logs the call is not matching the correct search rule. There is an auto generated rule that is configured when expressway-c does CUCM discovery. Even though this rule appears to be present, this call is not matching that rule..
Here is a sample trace..
Detail="Search rule 'CEtcp-10.21.30.51' did not match destination alias '3048@vcse.ctcari.com'"
Detail="Search rule 'CEtcp-10.24.35.51' did not match destination alias '3048@vcse.ctcari.com'"
Hence this call is then routed via a static rule you have defined..
Detail="Considering search rule 'Route to CUCM cluster' towards target 'to CUCM cluster' at priority '34' with alias '3048@ctcari.com'"
This is what a normal MRA search rule should look like..
Detail="Considering search rule 'CEtcp-uclabcucm-sub' towards target 'CEtcp-uclabcucm-sub' at priority '45' with alias 'uclabcucm-sub;transport=tcp;lr'"
From the logs this call doesn't proceed like a MRA call. You should check your configuration.
In any case the reason why this call is failing is because expressway-e sends an ACK to the 200 OK sent by expressway-c contains no SDP and the reason is because the original INVITE from sx20 to expwe doesn't have any SDP in it..
You should enable Early offer on the SIP profile, assigned to SX20.
Here is the original invite from expressway-e to c
SIPMSG:
|INVITE sip:3048@vcse.ctcari.com SIP/2.0
Via: SIP/2.0/TCP 10.24.60.60:7001;egress-zone=TraversalZone;branch=z9hG4bK8f364bb5e7476daa64cbc26c384f867e185.74d30421223a64a105b4ce8888d71c32;proxy-call-id=47008eee-6efa-46dd-b48d-62e57b2996fc;rport
Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK5f3c95e2e4dcdc9d7faa3f933a0f6737184
Call-ID: 57abbc1c8159bfb4@127.0.0.1
CSeq: 53699 INVITE
Contact: <sip:5000@10.24.60.60>
From: <sip:5000@10.24.60.60>;tag=f6d39a7b6cc30240
To: <sip:3048@vcse.ctcari.com>
Max-Forwards: 15
Record-Route: <sip:proxy-call-id=47008eee-6efa-46dd-b48d-62e57b2996fc@10.24.60.60:7001;transport=tcp;lr>
Allow: INVITE,ACK,BYE,CANCEL,INFO,REFER,NOTIFY
User-Agent: TANDBERG/4130 (X8.2.1)
Supported: com.tandberg.sdp.extensions.v1
Session-Expires: 1800
X-TAATag: def78012-00ee-49dc-854b-494a8414a3a8
Content-Length: 0
+++Here is the 200 OK sent to expressway-e+++
2014-10-03T07:49:54+00:00 vcsc tvcs: UTCTime="2014-10-03 07:49:54,356" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="10.24.35.60" Local-port="27900" Dst-ip="10.24.60.60" Dst-port="7001" Msg-Hash="11774566367986258095"
SIPMSG:
|SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.24.60.60:7001;egress-zone=TraversalZone;branch=z9hG4bK8f364bb5e7476daa64cbc26c384f867e185.74d30421223a64a105b4ce8888d71c32;proxy-call-id=47008eee-6efa-46dd-b48d-62e57b2996fc;received=10.24.60.60;rport=7001;ingress-zone=Traversalzone,SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK5f3c95e2e4dcdc9d7faa3f933a0f6737184
Call-ID: 57abbc1c8159bfb4@127.0.0.1
CSeq: 53699 INVITE
Remote-Party-ID: "Video Conference" <sip:3048@10.24.35.51>;party=called;screen=yes;privacy=off
Contact: <sip:3048@10.24.35.51:5080;transport=tcp>
From: <sip:5000@10.24.60.60>;tag=f6d39a7b6cc30240
To: <sip:3048@vcse.ctcari.com>;tag=2579360~91cc1d91-667d-4372-90da-1c05eb2a8169-35190722
Record-Route: <sip:proxy-call-id=4902fd4e-cbb8-4c37-9506-11ac8a3f51eb@10.24.35.60:5060;transport=tcp;lr>,<sip:proxy-call-id=4902fd4e-cbb8-4c37-9506-11ac8a3f51eb@10.24.35.60:5060;transport=tcp;lr>,<sip:proxy-call-id=47008eee-6efa-46dd-b48d-62e57b2996fc@10.24.60.60:7001;transport=tcp;lr>
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
Date: Fri, 03 Oct 2014 07:49:47 GMT
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Require: timer
Session-Expires: 1800;refresher=uas
P-Asserted-Identity: "Video Conference" <sip:3048@10.24.35.51>
Allow-Events: presence
Content-Type: application/sdp
Content-Length: 2322
v=0
o=CiscoSystemsCCM-SIP 2579360 1 IN IP4 10.24.35.51
s=SIP Call
c=IN IP4 10.24.35.60
b=AS:6000
t=0 0
m=audio 36462 RTP/AVP 108 9 104 105 0 8 15 18 101
+++Here is the ACK from expressway-e..It has no SDP++++
2014-10-03T07:49:54+00:00 vcsc tvcs: UTCTime="2014-10-03 07:49:54,466" Module="network.sip" Level="DEBUG": Action="Received" Local-ip="10.24.35.60" Local-port="27900" Src-ip="10.24.60.60" Src-port="7001" Msg-Hash="4202547894220715907"
SIPMSG:
|ACK sip:3048@10.24.35.51:5080;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.24.60.60:7001;egress-zone=TraversalZone;branch=z9hG4bKcf9e2914d572721747e9a7e386ecb5e6188.74d30421223a64a105b4ce8888d71c32;proxy-call-id=47008eee-6efa-46dd-b48d-62e57b2996fc;rport
Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK55e8fd88bc5667769422dfdc7309d6a9186
Call-ID: 57abbc1c8159bfb4@127.0.0.1
CSeq: 53699 ACK
From: <sip:5000@10.24.60.60>;tag=f6d39a7b6cc30240
To: <sip:3048@vcse.ctcari.com>;tag=2579360~91cc1d91-667d-4372-90da-1c05eb2a8169-35190722
Max-Forwards: 69
Route: <sip:proxy-call-id=4902fd4e-cbb8-4c37-9506-11ac8a3f51eb@10.24.35.60:5060;transport=tcp;lr>
Route: <sip:proxy-call-id=4902fd4e-cbb8-4c37-9506-11ac8a3f51eb@10.24.35.60:5060;transport=tcp;lr>
User-Agent: TANDBERG/4130 (X8.2.1)
Content-Length: 0
+++Immediately expressway-c drops the call+++
2014-10-03T07:49:54+00:00 vcsc tvcs: UTCTime="2014-10-03 07:49:54,467" Module="network.sip" Level="DEBUG": Action="Received" Local-ip="10.24.35.60" Local-port="27900" Src-ip="10.24.60.60" Src-port="7001" Msg-Hash="16036269070281652568"
SIPMSG:
|BYE sip:3048@10.24.35.51:5080;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.24.60.60:7001;egress-zone=TraversalZone;branch=z9hG4bK53734d656c62c35661d890ade77bb676189.74d30421223a64a105b4ce8888d71c32;proxy-call-id=47008eee-6efa-46dd-b48d-62e57b2996fc;rport
Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK684d4b4e2f573812858bf49ac87f1675187
Call-ID: 57abbc1c8159bfb4@127.0.0.1
CSeq: 53700 BYE
From: <sip:5000@10.24.60.60>;tag=f6d39a7b6cc30240
To: <sip:3048@vcse.ctcari.com>;tag=2579360~91cc1d91-667d-4372-90da-1c05eb2a8169-35190722
Max-Forwards: 69
Route: <sip:proxy-call-id=4902fd4e-cbb8-4c37-9506-11ac8a3f51eb@10.24.35.60:5060;transport=tcp;lr>
Route: <sip:proxy-call-id=4902fd4e-cbb8-4c37-9506-11ac8a3f51eb@10.24.35.60:5060;transport=tcp;lr>
User-Agent: TANDBERG/4130 (X8.2.1)
Content-Length: 0
10-05-2014 10:51 PM
Hi Okanlawon
First thank you very much for your input.Five stars to you
1) About certificates.Pls correct me if i am wrong
Generate certificates from EXPE upload to Public CA and then upload the certificate to EXPE
Then change certificates from expe and expc.
I will not upload a public certificate into EXPC because is only for inside network .
2) About the other issue with the incoming calls i think something else is happening
The call going to sx20 or to any other extension via MRA ( through EXPE) and when we answer the call then the call drop
So its matching successfully the rules ( because is reach the endpoint) but after the answer the call id drop down///
Any input about that?
Traces from both ExpE-ExpC?
10-05-2014 11:23 PM
1. You need to exchange certificate between expc and expwe. Please read the security deployment guide. Using certificate between expc and cucm is optional.
2. Your test call though its going through epxwe, is not a MRA call. I gave you a detailed explanation above. Another thing that is incorrect is that your cucm servers are defined with ip address, this wont work with MRA. This is why your auto generated rule is not working. When expwc creates the serach rule, it uses the format 'CEtcp-hostname'
This hostname needs to be what you configure on cucm and also in your UDS DNS SRV records.
3. I gave you lots of thoughts on why your call is failing..Please read the log analysis and my suggestion....enable early offer on your SX20 sip profile..
11-03-2014 05:14 AM
The issue with the incoming calls to sx20 resolved by disable the NAT into router for the h323 signaling.
no ip nat service H225
/cc
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide