Re: Cisco CUBE FXS Port with fax machine unable to send fax to external using ITSP SIP service

ragz3000 · ‎06-05-2019

Issue – Recently migrated from ISDN to SIP service. Now unable to send fax calls using T.38 fax-relay protocol. CUBE initiates the voice call to external party but it does not switchover to a fax tone i.e. T.38 fax-relay during the call.

Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_save_fax_config:
Fax Relay=ENABLED
Primary Fax Protocol=T38_FAX_RELAY, Fallback Fax Protocol=NONE_FAX_RELAY
Fax Relay CM Suppression :=ENABLED, Fax Relay ANS Suppression :=DISABLED
Fax Parameters Set By=Dialpeer, Peer=113
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_save_fax_config:
Fax Version:=0, LS Red=0, HS Red=0
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_set_fax_feat_param:
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_save_tty_config:
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_save_tty_config:
Save TTY configuration
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_set_tty_feat_param:
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_set_tty_feat_param:
Set TTY feat parameters
Jun 5 14:53:02.336: //52025/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Jun 5 14:53:02.336: cc_api_get_xcode_stream : 4981
Jun 5 14:53:02.336: //52025/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Jun 5 14:53:02.336: cc_api_get_xcode_stream : 4981
Jun 5 14:53:02.336: //52025/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Jun 5 14:53:02.336: cc_api_get_xcode_stream : 4981
Jun 5 14:53:02.336: //52025/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Jun 5 14:53:02.336: cc_api_get_xcode_stream : 4981
Jun 5 14:53:02.336: //52025/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Jun 5 14:53:02.336: cc_api_get_xcode_stream : 4981
Jun 5 14:53:02.336: //52025/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:

Jun 5 14:53:02.336: cc_api_get_xcode_stream : 4981
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/cc_api_bridge_done:
Conference Id=0x2C0F, Source Interface=0x15FF6D48, Source Call Id=52025,
Destination Call Id=52023, Disposition=0x0, Tag=0x0
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/cc_generic_bridge_done:
Conference Id=0x2C0F, Source Interface=0x15FF6D48, Source Call Id=52025,
Destination Call Id=52023, Disposition=0x0, Tag=0x0
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x2C0F, Destination Call Id=52025)
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x2C0F, Destination Call Id=52023)
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/ccConferenceCreate:

Jun 5 14:53:02.336: confID:0x2C0F; callEntry1 callID1:0xCB37, type:6; callEntry2 callID2:0xCB39, type:3

Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_process_event:
[state:S_PROCEEDING, event:E_CC_PROGRESS]
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/act_progress:
Progress Indication=8
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_timer_stop:
Timer Stop Time=79755429
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_open_packet_path:
Progress Indication=8
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_open_packet_path: Setting pak_suppress to DSP_PAK_SUPPRESS_DISABLE
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_process_event:
[state:S_PROCEEDING, event:E_CC_DO_CAPS_IND]
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_peer_event_cb:
Event=E_DSM_CC_CAPS_IND
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/cc_api_caps_ind:

Jun 5 14:53:02.336: voice_rtp_nse_payload 0, voice_rtp_sse_payload 118 voice_sprt_payload 120
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/cc_api_caps_ind:

Jun 5 14:53:02.336: sprt_latency 200, sprt_retries 12
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/cc_api_caps_ind:
Destination Interface=0x15FF6D48, Destination Call Id=52025, Source Call Id=52023,
Caps(Codec=0x1, Fax Rate=0x1, Fax Version:=0, Vad=0x1,
Modem=0x2, Codec Bytes=20, Signal Type=3)
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/cc_api_caps_ind:

Jun 5 14:53:02.336: voice_rtp_nse_payload 0, voice_rtp_sse_payload 118 voice_sprt_payload 120
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/cc_api_caps_ind:

Jun 5 14:53:02.336: sprt_latency 200, sprt_retries 12
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/cc_api_caps_ind:
Destination Interface=0x16501BC0, Destination Call Id=52023, Source Call Id=52025,
Caps(Codec=0x2, Fax Rate=0x2, Fax Version:=0, Vad=0x1,
Modem=0x0, Codec Bytes=160, Signal Type=2)
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Jun 5 14:53:02.336: //52025/991D81938368/CCAPI/cc_api_caps_ack:
Destination Interface=0x16501BC0, Destination Call Id=52023, Source Call Id=52025,
Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=2051)
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_process_event:
[state:S_PROCEEDING, event:E_CC_CAPS_IND]
Jun 5 14:53:02.336: //52023/991D81938368/VTSP:(0/1/1):-1:1:4/vtsp_dsm_peer_event_cb:
Event=E_DSM_CC_CAPS_ACK
Jun 5 14:53:02.336: //52023/991D81938368/CCAPI/cc_api_caps_ack:
Destination Interface=0x15FF6D48, Destination Call Id=52025, Source Call Id=52023,
Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=2051)

Jonathan Schulenberg · ‎06-05-2019

Who is your carrier? Verizon doesn’t support TGW-initiated switchover. That’s why it only breaks outbound T.38 because the TGW for an inbound call will be the DSP of the FXS port which behaves normally. Unfortunately, you’re likely stuck here if the carrier won’t initiate the switchover.
https://www.cisco.com/c/en/us/support/docs/voice/t38/116280-configure-cube-00.html#anc24

ragz3000 · ‎06-05-2019

Carrier is Vocus in Australia.

They are asking us to buy their standard ATA and connect fax machine, then they will remove the FAX DID numbers from SIP trunk to get this working.

I have not heard about this before and am really confused.

Jonathan Schulenberg · ‎06-05-2019

Originating and Terminating Gateways: the VoIP gateway nearest the calling and called parties, respectively. The normal behavior is for the TGW - the VoIP to TDM/analog gateway nearest the called party - to recognize the CNG tone and initiate the switchover process.
https://www.cisco.com/c/en/us/support/docs/voice/session-initiation-protocol-sip/118647-technote-sip-00.html

ragz3000 · ‎06-05-2019

Calling Device -> CUBE -> SIP Trunk -> Called Device

OGW TGW

As I understand once voice call is established,

The TGW waits to detect V.21 Preamble in the tones. It finds it in CED tone (G3) or ANSAM (SG3). Once it detects the V.21 Flag, it initiates switchover.

Check for VTSP shows:

VTSP: Event=E_DSMP_DSP_FAX_TONE

Check for DSMP shows:
E_DSM_CC_MC_START

Check for CCAPI shows:
CCAPI:Caps(Codec=T38Fax(0x10000), Fax Rate=FAX_RATE_14400(0x80),Fax Version:=0, Vad=OFF(0x1),

I enabled all below debugs

debug voip vtsp all
debug ccsip events
debug voip ccapi inout
debug ccsip messages
debug fax relay t30 all-level-1

from the logs I do not see VTSP: Event=E_DSMP_DSP_FAX_TONE, who should send this tone? OGW or TGW?

As you your recent reply OGW should send CNG tone.