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

TCP/TLS Interworking 4400

rchaseling
Level 4
Level 4

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?

1 Accepted Solution

Accepted Solutions

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

View solution in original post

5 Replies 5

M02@rt37
VIP
VIP

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:

https://supportforums.cisco.com/t5/collaboration-voice-and-video/cube-sipsecure-control-with-rtp-to-srtp-internetworking-with/ba-p/3383388

 

 

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

R0g22
Cisco Employee
Cisco Employee
Are you trying to do an end to end TLS or is it TCP to TLS ? Can you attach your config from the CUBE here ? Also, collect the following -

debug ccsip message
debug ccsip error
debug ccsip info
debug voice ccapi inout
debug ip tcp transaction

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

 

 

 

 

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

Jonathan Schulenberg
Hall of Fame
Hall of Fame
I believe you need to add “srtp fallback” to allow interworking between RTP and SRTP call legs.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/srtp-rtp-interworking.html