The ATA186 doesn't support T.38 faxing, only NSE-based fax passthrough which no SIP carrier I'm aware of supports since it is Cisco-proprietary and part of the media, not signaling, flow. The passthrough feature (not pass-through which is a different thing that the ATA186 also doesn't support) is a relic from when VoIP stopped at the PSTN gateway and was converted back into TDM/analog.
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/ata-180-series-analog-telephone-adaptors/19083-ata-fax.html
http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/115742-fax-modem-call-flows-00.html#anc6
Since the carrier doesn't support passthrough the call will proceed as a normal voice call, inclusive of whatever the normal voice call codec is, dejiter buffers, VAD (if enabled), etc. You will have very low success rates using this method.
If you want T.38 then you would need to use a VG202/204, the newer ATA190, or an FXS port on an ISR router.
With that said, there is actually a second problem here.
Here's the RE-INVITE from the ITSP requesting a T.38 switchover. Since the ITSP is making the request this must have been an outbound call (the terminating gateway initiates the switchover).
Sep 2 14:34:59.265: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:02969****@10.102.*.*:5060 SIP/2.0
Via: SIP/2.0/UDP 10.102.*.*:5060;branch=z9hG4bKvbeene206o5blbq7g2k0sb0000g00.1
Call-ID: 3B2B41FE-705111E6-9ADEDC1D-E5C2C1AE@10.102.*.*
From: <sip:02974****@10.102.*.*>;tag=SDrq7r899-vps2grrs-CC-34
To: "fax 2197 - blok 306" <sip:02969****@10.102.*.*>;tag=3E5C794-1DFF
CSeq: 1 INVITE
Contact: <sip:02974****@10.102.*.*:5060;transport=udp>
Max-Forwards: 69
Content-Length: 425
Content-Type: application/sdp
v=0
o=Vivacom 11299122 11299124 IN IP4 10.102.*.*
s=Sip Call
c=IN IP4 10.102.*.*
t=0 0
m=image 20168 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 20282 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
a=fmtp:101 0-15
Which CUBE doesn't include when sending it on to CUCM:
Sep 2 14:34:59.293: //5134/63D7CC800000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:02969****@10.20.*.*:5060 SIP/2.0
Via: SIP/2.0/UDP 10.20.*.*:5060;branch=z9hG4bK4A922FC
Remote-Party-ID: <sip:02974****@10.20.*.*>;party=calling;screen=no;privacy=off
From: <sip:02974****@10.20.*.*>;tag=3E5CA68-3D2
To: "fax 2197 - blok 306" <sip:02969****@10.20.*.*>;tag=302038~0ca2d289-019a-4842-a7cf-4124ee03f828-25700970
Date: Fri, 02 Sep 2016 14:34:59 GMT
Call-ID: 63d7cc80-7c918e06-5b00-8a04140a@10.20.*.*
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 1675086976-0000065536-0000015771-2315523082
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1472826899
Contact: <sip:02974****@10.20.*.*:5060>
Call-Info: <sip:10.20.*.*:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 212
v=0
o=CiscoSystemsSIP-GW-UserAgent 7524 6021 IN IP4 10.20.*.*
s=SIP Call
c=IN IP4 10.20.*.*
t=0 0
m=audio 17516 RTP/AVP 8
c=IN IP4 10.20.*.*
a=rtpmap:8 PCMA/8000
a=ptime:20
a=silenceSupp:off - - - -
Your call is not matching the dial-peers you expect it to. Instead, it appears to be matching dial-peer 0. As evidence of this, notice that the RE-INVITE to CUCM is offering only G.729 even though your dial-peers are configured with G.711 a-law.
Because of this CUCM never thinks to offer T.38 in the response, though it wouldn't have even if given the option since the ATA186 doesn't support T.38. When CUBE eventually responds to the ITSP to finish the media renegotiation, it rejects the T.38 switchover by setting the UDP port to zero. Worse still is that it only offers G.729 which will never work for fax calls. This is why the carrier responds with a BYE.
Sep 2 14:34:59.373: //5135/63D7CC800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.102.*.*:5060;branch=z9hG4bKvbeene206o5blbq7g2k0sb0000g00.1
From: <sip:02974****@10.102.*.*>;tag=SDrq7r899-vps2grrs-CC-34
To: "fax 2197 - blok 306" <sip:02969****@10.102.*.*>;tag=3E5C794-1DFF
Date: Fri, 02 Sep 2016 14:34:59 GMT
Call-ID: 3B2B41FE-705111E6-9ADEDC1D-E5C2C1AE@10.102.*.*
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "fax 2197 - blok 306" <sip:02969****@10.102.*.*>;party=called;screen=yes;privacy=off
Contact: <sip:02969****@10.102.*.*:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Supported: timer
Content-Type: application/sdp
Content-Length: 424
v=0
o=CiscoSystemsSIP-GW-UserAgent 2147 9635 IN IP4 10.102.*.*
s=SIP Call
c=IN IP4 10.102.*.*
t=0 0
m=image 0 udptl t38
c=IN IP4 10.102.*.*
a=rtpmap:8 PCMA/8000
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transfer
Voice_GW-2#redTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=silenceSupp:off - - - -
m=audio 18726 RTP/AVP 8
c=IN IP4 10.102.*.*
a=rtpmap:8 PCMA/8000
a=ptime:20
a=silenceSupp:off - - - -
You should review your dial-peer configuration to see why calls aren't matching what you expect them to. The best you can hope for here is a normal G.711 voice call with the analog fax transmission carried within it. In practice, this isn't reliable: a single lost/delayed/out-of-order RTP packet can cause the whole page to fail transmission.
