06-29-2018 08:42 AM - edited 03-15-2019 05:41 AM
Hi,
Having a strange issue on a new setup that I can only assume is something so simple I've missed it
I have a 4431 CUBE with Security licensing which I need to convert TCP/RTP to TLS/sRTP before sending through a firewall and out to the internet
I have configured 4431s with TCP/TLS interworking before so I have known working config to reference though have always done it with UCM to CUBE as TLS and CUBE to ITSP as TCP. This callflow is Ingress 2921 GW (TCP)--> 4431 CUBE (TLS)--> Firewall --> Internet
The issue I have here is I am receiving the TCP invite (from ingress GWG) and my 4431 sends back the Trying but it never sends the Outbound TLS invite at all. My dialpeer config is correct because If I change my outbound dialpeer to TCP it works.
For some reason my 4431 will not initiate an outbound TLS invite at all
Below is the relevant config I believe
!
dspfarm profile 1 transcode universal
codec g711alaw
codec g711ulaw
codec g729r8
maximum sessions 40
associate application CUBE
!
dial-peer voice 1 voip
description FROM INGRESS GW
translation-profile incoming GW-IN
session protocol sipv2
session transport tcp
incoming called e164-pattern-map 100
voice-class sip bind control source-interface Port-channel1.402
voice-class sip bind media source-interface Port-channel1.402
dtmf-relay rtp-nte
codec g711alaw
no vad
!
dial-peer voice 2 voip
description OUTBOUND
translation-profile outgoing OUTBOUND
session protocol sipv2
session target dns:abc.com
session transport tcp tls
destination e164-pattern-map 100
voice-class sip bind control source-interface BDI403
voice-class sip bind media source-interface BDI403
dtmf-relay rtp-nte
srtp
codec g711alaw
no vad
THe only think I can think of is that 5061 is not open on the far end yet.....but the 4431 should still at least send the Invite right?
Solved! Go to Solution.
07-04-2018 04:34 AM
All,
This may be common knowledge to some but wan't to me. If your TCP port is not open at the destination IP your outbound dialpeer is pointing to.... CUBE does not even attempt an INVITE
It just sits there for 20 seconds trying to make a TCP connection and will then jsut send a 503 back to the originator.
What threw me here was that 2 things:
1. In this instance here the far end did have 5060 open rather than 5061 which was why the TCP invites were working and the TLS not. a typo on the far end provider
2. I never saw any traffic generated at all by the CUBE to the far end when doing a packet capture from CUBE. If I had seen a TCP SYN to 5061 with no reply I would have twigged. Maybe a didn't take a capture for long enough.....not sure how often it will try....but you'd think it would try a TCP SYN on every call attempt
Anyway hope this helps someone
07-01-2018 11:35 AM - edited 07-01-2018 11:49 AM
Hi @rchaseling
Do you check on your firewall (monotoring or dump) if you see an INVITE TCP/TLS from your CUBE 4431?
Do you have something configured on your sip-ua menu?
Please @rchaseling check if you have configured on sip-ua the crypto signaling default trustpoint command and the transport tcp tls command too.
Please check also my blog if this can help you:
07-01-2018 11:41 AM
07-02-2018 01:41 AM - edited 07-02-2018 02:21 AM
Hi,
Thanks to all for coming back to me. I'll try and answer all here
++ I'm trying to do TCP/TLS interworking. TCP on inside network/TLS on outside of CUBE
++ I've attached running config <ommited> some stuff. Let me know if I've removed too much & I've also attached dubugs requested
++ I've no access to the firewall but I've done a packet capture from external CUBE interface and see the same results as the SIP debugs
++ I have the trustpoint configured under sip-ua (correctly I beleive)
I notice on that official Cisco doc that it say a requirement for TCP/TLS interworking is CUCM Manager 7 or above.......does this mean that I cannot do interworking without CUCM??????
THanks
07-04-2018 04:34 AM
All,
This may be common knowledge to some but wan't to me. If your TCP port is not open at the destination IP your outbound dialpeer is pointing to.... CUBE does not even attempt an INVITE
It just sits there for 20 seconds trying to make a TCP connection and will then jsut send a 503 back to the originator.
What threw me here was that 2 things:
1. In this instance here the far end did have 5060 open rather than 5061 which was why the TCP invites were working and the TLS not. a typo on the far end provider
2. I never saw any traffic generated at all by the CUBE to the far end when doing a packet capture from CUBE. If I had seen a TCP SYN to 5061 with no reply I would have twigged. Maybe a didn't take a capture for long enough.....not sure how often it will try....but you'd think it would try a TCP SYN on every call attempt
Anyway hope this helps someone
07-01-2018 01:49 PM
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