cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3689
Views
20
Helpful
9
Replies

CSR 1000V not sending INVITE when configured for TCP

Hello,

 

In labbing out a CSR 1000V, we ran into an issue where INVITE messages stopped being sent out when SIP control was configured for TCP, throwing the following error:

 

 %SIP-3-INTERNAL: TCP_SOCKET_SEND_BLOCKED: connid=24, local_addr=192.168.64.4, remote_addr=54.244.51.1, remote_port=5060 - All retries are exhausted, deleting pending messages. 

 

Pcaps confirm that no sip message is sent, though there is a successful tcp handshake for each attempt. Trunk is authenticated with no TLS. If anyone has seen something like this please let me know. I've attached logs and configs for the curious.

 

Thanks in advance,

 

Brian Warlick

1 Accepted Solution

Accepted Solutions

Was this from the firewall ingress or egress ? I am assuming ingress.

I am attaching a PDF containing the flow graph for the TCP transactions. You can see that the router is able to successfully establish a 3-way handshake with all three ITSP IP's but your ITSP stops responding after that. Towards the end you would see RST being initiated by all three IP addresses towards the router.

 

Has your ITSP confirmed the ports that need to be used ? Right now you are using a source ephemeral port and a destination port of 5060. This is the default behavior for IOS.

 

 

View solution in original post

9 Replies 9

R0g22
Cisco Employee
Cisco Employee
Nothing much can be deduced from the logs. Can you get a "ccsip all" alongwith "ccapi inout" and "ip tcp transactions" debug for a failed call instance using TCP ? Taken the fact you have this in lab, we should be good with the logs from these.

I enabled "ccsip all" and "ip tcp transactions"and attached output. I did not see ccapi inout as a valid debug option. Below is the version currently running:

 

Cisco IOS XE Software, Version 16.03.05
Cisco IOS Software [Denali], CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.3.5, RELEASE SOFTWARE (fc1)

 

Thank you for taking the time to help.

 

It would have been "debug voice ccapi inout". My bad I abbreviated it. Anyways, this looks like a TCP issue rather than a SIP issue -

Feb 14 17:53:35.186: //-1/xxxxxxxxxxxx/SIP/Transport/sipConnectionManagerProcessConnCreated: connection instance created for addr:54.244.51.2, port:5060 local_addr=192.168.64.4 local_port=14351

Feb 14 17:53:35.187: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportStopConnWaitTimer: Wait timer stopped for connection=0x7F22CF516E68,addr=54.244.51.2, port=5060
Feb 14 17:53:35.187: //-1/xxxxxxxxxxxx/SIP/Transport/sipInstanceHandleConnectionCreated: Moving connection=0x7F22CF516E68, connid=30 state to established. local_addr=192.168.64.4, local_port=14351
Feb 14 17:53:35.187: //16/F43F8B000000/SIP/Transport/sipTransportPostInternalMsg: Posting Internal Msg type=0
Feb 14 17:53:35.187: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 for event 62
Feb 14 17:53:35.187: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting send for msg=0x7F22CE955AF0, addr=54.244.51.2, port=5060, local_addr=192.168.64.4, connId=30 vrfid=0 for TCP
Feb 14 17:53:35.187: //16/F43F8B000000/SIP/Info/info/512/sentInviteRequest: Sent Invite in state STATE_IDLE

Feb 14 17:53:35.201: TCB7F2265B287E0 setting property TCP_TOS (11) 7F226FA1F488
Feb 14 17:53:35.201: //-1/xxxxxxxxxxxx/SIP/Info/sip_tcp_resend: Socket blocked requeue data
Feb 14 17:53:35.210: TCB7F2265B287E0 setting property TCP_TOS (11) 7F226FA1F488
Feb 14 17:53:35.210: //-1/xxxxxxxxxxxx/SIP/Info/sip_tcp_resend: Socket blocked requeue data
Feb 14 17:53:35.221: TCB7F2265B287E0 setting property TCP_TOS (11) 7F226FA1F488
Feb 14 17:53:35.221: //-1/xxxxxxxxxxxx/SIP/Info/sip_tcp_resend: Socket blocked requeue data
Feb 14 17:53:35.234: TCB7F2265B287E0 setting property TCP_TOS (11) 7F226FA1F488
Feb 14 17:53:35.234: //-1/xxxxxxxxxxxx/SIP/Info/sip_tcp_resend: Socket blocked requeue data

Feb 14 17:53:37.505: %SIP-3-INTERNAL: TCP_SOCKET_SEND_BLOCKED: connid=30, local_addr=192.168.64.4, remote_addr=54.244.51.2, remote_port=5060 - All retries are exhausted, deleting pending messages
Feb 14 17:53:37.505: //-1/xxxxxxxxxxxx/SIP/Error/sip_tcp_resend:
TCP_SOCKET_SEND_BLOCKED: connid=30, local_addr=192.168.64.4, remote_addr=54.244.51.2, remote_port=5060 - All retries are exhausted, deleting pending messages

Feb 14 17:53:37.819: TCP0: RETRANS timeout timer expired
Feb 14 17:53:37.820: 192.168.64.4:14351 <---> 54.244.51.2:5060 congestion window changes
Feb 14 17:53:37.820: cwnd from 536 to 536, ssthresh from 65535 to 1072
Feb 14 17:53:37.820: TCP0: timeout #1 - timeout is 5250 ms, seq 2043988231
Feb 14 17:53:37.820: TCP: (14351) -> 54.244.51.2(5060)

Feb 14 17:53:38.688: //16/F43F8B000000/SIP/Error/act_sentinvite_wait_100:
Out of retries

Is "54.244.51.2" your ITSP ?

Yes ITSP is 54.244.51.2, .1, and .0

 

Please let me know if you would still like the debug voice ccapi inout output and i can run out and generate another log.

Nope. No need for the logs. I already told you what the issue is. Does your ITSP support TCP ? Is there a firewall in the path that you can check or take a pcap from ?

The ITSP supports TCP transport. I've attached a pcap from a call attempt from the lab firewall. I'm also checking with our security team to make sure there's nothing else this needs to be whitelisted on.

 

It didn't let me attach a .cap file so added .txt to the filename.

Was this from the firewall ingress or egress ? I am assuming ingress.

I am attaching a PDF containing the flow graph for the TCP transactions. You can see that the router is able to successfully establish a 3-way handshake with all three ITSP IP's but your ITSP stops responding after that. Towards the end you would see RST being initiated by all three IP addresses towards the router.

 

Has your ITSP confirmed the ports that need to be used ? Right now you are using a source ephemeral port and a destination port of 5060. This is the default behavior for IOS.

 

 

Well i feel rather sheepish... Security did have another firewall hiding in there. They whitelisted the source/dest on it and messages started flowing. Thank you for all the help.

Cheers! Have a nice one !

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: