Outbound SIP calls dropping after 3 seconds

[davidstillert]

I'm trying to configure a vCube with a SIP provider IXICA and I have inbound calls working but outbound calls drop after 3 seconds whether answered or not.   It appears as though I'm sending and ACK and right after that a SIP "BYE" message but I can't figure out where the kink is.

THE UC platform is 11.5 which consists of a PUB and SUB with a vCube running on a demo license.  The provider uses G711 so I'm not see codec issues.   

I've attached a show run and show ccsip all from the vCube during an outbound call.   Any help would be appreciated.

[R0g22]

There is a TCP failure -

Mar 7 09:10:13: //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostCloseConnection: Posting TCP conn close for addr=10.150.19.102, port=5060, local_addr=50.50.230.230, connid=32
Mar 7 09:10:13: //-1/xxxxxxxxxxxx/SIP/Transport/sipDeleteConnInstance: Deleted conn=0x7F34F3E67880, connid=32, addr=10.150.19.102, port=5060, local_addr=50.50.230.230, transport=TCP
Mar 7 09:10:13: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 for event 62
Mar 7 09:10:13: //374/3C7F25800000/SIP/Error/sipTransportPostSendFailure:
Posting send failure msg with tcb:0x0 reason=5

Who is "10.150.19.102" ? Is there a firewall at the edge after the vCUBE ?
A couple of more things -
1. The logs are not complete. There are message drops. I don't see the INVITE to your ITSP but it does happen.
2. I don't see a change of TCP transport on the CUBE so it is defaulting to UDP. Not sure why is their a TCP happening here.

Take another set of logs using the following config and debugs -
conf t
no logg rate
no logg queue
no logg trap
no logg source

debug ccsip message
debug ccsip error
debug ccsip info
debug voice ccapi inout

[davidstillert]

OK so I've done another debug which is attached.  For simplicity sake I've changed the CUCM > Cube SIP trunk to UDP and defined UDP on all voip dial-peers.  On an outbound call I now get one way audio but it still disconnects after 3 seconds. 

10.150.19.102 is the SUB

10.150.19.101 is the PUB

10.150.19.111 is the vCube lan interface

10.150.19.11 is the ip phone with ext 22150

50.50.230.230 is the vCube external interface

The DID provided via IXICA is 5193431050

Then number i'm calling out to is 4165552121

 Thanks for looking at it.....

[R0g22]

The logs are still not complete. I noticed that you are taking the logs on the terminal rather than buffer. There are a good number of lines being printed so the IOS is dropping the messages.
From what I could gather, the cause is different now -

Mar 7 12:34:18: //1249/BD4C1A800000/SIP/Error/act_sentsucc_wait_ack:
Out of retries
Mar 7 12:34:18: //1249/BD4C1A800000/SIP/Info/critical/4096/ccsip_set_cc_cause_for_spi_err: Categorized cause:102, category:129
Mar 7 12:34:18: //1249/BD4C1A800000/SIP/Info/verbose/4096/ccsip_set_release_source_for_peer: ownCallId[1249], src[6]

The IOS sends a 200 OK but your sub never acks it. IOS times out post retry attempts and drops the call.
This would also explain the earlier TCP issue. The TCP with your sub was dropping which was causing the calls to fail. Not an issue with CUBE.

To further isolate, have the Pub initiate the call and see if that works.

[davidstillert]

I shut down the sub and calls now stay connected for 5 seconds however they still drop.  I've logged to flash and have attached it.

[R0g22 · Accepted solution]

Ok my bad. I didn't pay attention to the IP addresses being relayed due to lack of complete logs.
The CUBE is selecting incorrect IP addresses due to incorrect dial-peer selection.

CUBE is selecting DP 100 which has a binding for your external interface, which is incorrect.

Do the following -
conf t
voice class uri IN sip
host ipv4:10.150.19.102
host ipv4:10.150.19.101

dial-peer voice 1000 voip
description CUCM INBOUND
session protocol sipv2
incoming uri via IN
voice-class sip options-keepalive
voice-class sip bind control source-interface GigabitEthernet2
voice-class sip bind media source-interface GigabitEthernet2
dtmf-relay rtp-nte
codec g711ulaw
no vad

Test your calls after this with both SUB and PUB. No need to change anything else. If it works with UDP, test with TCP as well. It should work fine.

Apologies regarding the confusion.

[davidstillert]

Well that did it.  Everything appears to be working.  I've flipped the CUCM trunk back to TCP.  I'm still a bit confused as to why it was pulling the wrong dial-peer but I think I understand the logic.  Which leg of the call did this dialpeer fix?   Cube back to CUCM?

Thanks for taking the time to 

[R0g22]

Yes so the inbound dial-peer getting selected on the CUBE for your outbound calls was 100 which was binded to the external CUBE interface. This was happening due to the "incoming called-number ." command. The IOS really cares to find a VoIP DP to tie the incoming leg. It does not care where the call is coming for. So with that the "200 OK" being sent to CUCM was from your CUBE external IP which from CUCM's perspective is like "well, I don't know who that guy is", so it does not respond.

With this new dial-peer, we are adding incoming DP selection based upon the host i.e. your SUB and PUB. So now,

1. Calls coming in from your ITSP will select DP 100 which has the correct external binds.
2. Calls from CUCM will select DP 1000 for call originating from CUCM which has the correct internal bind.
3. Your outbound DP's in either direction already have correct binds in place.