cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4968
Views
0
Helpful
8
Replies

Question regarding T38

tca_arosen
Level 1
Level 1

I have been having problems getting faxing over T38 working and I am wondering if my understanding of the protocol is part of the issue. Our scenario is:

ITSP >>>>SIP>>>> CUBE 2911 >>>>SIP>>>> CUCM 9.1.2

                                         |-> FXS port (configured via MGCP) >>> Fax printer

 

When trying to fax, our CUBE responded with a "488 Not Acceptable Media" in response to the T38 m=image message from our ITSP. In my gateway configuration in CUCM I ended up disabling T38 fax relay and faxes worked. For reference, my dial peer to our ITSP was configured with "fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none"

My question is, did I actually use T38 to fax, or was I in a passthrough mode whose performance will be unpredictable going forward? My understanding is that with a low-end fax machine like I was using, the path would be:

Fax >>>AUDIO>>>CUBE>>>T38>>>ITSP

Is T38 supposed to be supported on the fax machine? Or by having the "T38 fax relay" configured on the CUBE was it trying to relay the T38 message directly to the fax machine and not getting a response (which it can't since it's not an IP connection), thereby generating the 488 message? Is there a way I can debug this? "show call history fax" shows all 0s, so I don't think I have things configured properly.

I would appreciate any help possible. I didn't think this would be so complex!

Thanks

Adam

 

1 Accepted Solution

Accepted Solutions

That output looks fine to me. Receiving the test page on the other side with complete integrity means everything's working ok.

You will need to speak to your vendor about that sip profile. I'm not sure why one would want to remove the connection information from the SDP. It is an important field which tells the other side where to send the media! Even if there is more than 1 instance of the connection field, it's alright. It has to be there for the other side to process the sdp correctly.

View solution in original post

8 Replies 8

Sreekanth Narayanan
Cisco Employee
Cisco Employee

Hi Adam,

The CUBE will respond with 488 when the incoming call has something in the m line that the cune cannot process. Since you are talking about m=image, this would mean you are doing an outbound fax call to the itsp, and you receive an Invite message from the ITSP for the switchover.

How many m lines are present in the Invite coming from the ITSP? If it is more than 1, CUBE cannot process it.

Yes,  you have to set the t38 command on the dial-peer which is matched on the inbound leg, as well as the dial-peer that is matched on the outbound leg to the CUCM. You cannot have fax pass-through on one side and t38 on the other. CUBE cannot convert between the two of them.

 

To find out why the cube responded with 488, you can use the debug ccsip info, ccsip message, ccsip error commands to print out the logs you need. debug voip ccapi inout will also help.

 

Thanks

Sreekanth

As I am working this and another couple of issues, I am learning some more of the debug tools. Looking at the real-time data from RTMT, I'm seeing that CUCM is sending the 488 message to the CUBE. I did not realize that CUCM would be involved here - I thought all this processing would be done on the CUBE side (I'm still trying to understand where they tie together for some processes). 

I have attached the logs captured. I don't know how to interpret the reason for the failure. I am still not clear on where the T38 protocol terminates. Is it the fax machine (which doesn't make sense to me since it's connected via an FXS port), CUCM or CUBE? Which piece is in charge of converting the analog signal into the T38 data? Intuitively I thought it was the CUBE, but now I see CUCM sending a 488 over to CUBE in RTMT. Which piece is failing?

Thanks for the help.

Adam

Ah well I think the reason why CUCM is sending the 488 is due to the other leg not being able to accept the media. The other leg is mgcp, and so when the m=image udptl comes to the CUCM, it will try to do t38 on te mgcp leg. If the mgcp leg does not support t38, the CUCM will be forced to send 488 on the sip leg.

What is the mgcp device? Is it a gateway with fxs ports or a vg224? Please make sure that the following configuration is present on the device for t38 to work on it.

no ccm-manager fax protocol cisco               
no mgcp fax t38 inhibit  
mgcp package-capability fxr-package
mgcp default-package fxr-package
no mgcp fax t38 ecm
mgcp fax t38 nsf 000000

 

Then do no mgcp, mgcp on the gateway to re-register it to UCM.

I am working on a 2911 router with an FXS card. I tried your changes but it didn't work. Then I did a mgcp fax t39 inhibit and it worked properly. Looking at the debug logs it looks like T38 is terminating at the CUBE instead of being passed to CUCM, but I'm really not sure. The logs seem to show it setting up a T38 session, but I'm not positive I'm reading it right. For example:

 

002179: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/sipSPIBwCacCalcMaxAudioBandwidth: Voice -> Fax Switchcodec T38Fax bytes 20
002180: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/sipSPIBwCacCalcMaxAudioBandwidth: max bw (including pak overhead) from preffered codecs: codec T38Fax bw 0
002181: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/sipSPI_ipip_negotiate_t38_caps: 
002182: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/sipSPIBwCacCalcMaxFaxBandwidth: Local Negotiated T.38 Fax Rate 14400 (bps) Fax Version 0
002183: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/sipSPIBwCacCalcMaxFaxBandwidth: Max T.38 Fax BW (bps) 14400 fax bit rate 20480 Fax HS Red 0
002184: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/ccsip_ipipms_peer_chnl_ind_hdlr: CHNL IND  Voice ->Fax Switch
002185: May 30 14:17:57.777: //271/AD9029000000/SIP/Info/ccsip_ipipms_peer_chnl_ind_hdlr: CHNL IND audio bw 0 bps video bw 0 bps fax bw 20480 bps

I've attached the log of a working fax to this message.

Adam

 

>> It looks like you made an inbound fax call, because here's the Invite coming
from CUCM containing the m=image line for doing t38. This means the mgcp side
accepted the t38 mode and CUCM then sends t38 caps on the sip leg. If no MTP is
invovled, the IP address below (216.214.138.230) will be the gateway where the
fax is connected.

001935: May 30 14:17:57.765: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:7161112222@64.61.165.70:5060 SIP/2.0
Via: SIP/2.0/UDP
216.214.138.230:5060;branch=z9hG4bK16tvra20c8hhojcjn1s1sbb9qha62.1
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info,
as-feature-event
Max-Forwards: 69
Call-ID: 84F607C9-E75D11E3-8149A59F-A8EBCD0@64.61.165.70
From: <sip:6251077@216.214.138.230>;tag=172.17.4.5+1+5df25+f467aebe
To: "TCA Fax" <sip:7161112222@64.61.165.70>;tag=3848F4-177D
CSeq: 736733324 INVITE
Expires: 180
Contact: <sip:6251077@216.214.138.230:5060;transport=udp>
Organization: MetaSwitch
Supported: resource-priority, 100rel
Content-Length: 231
Content-Type: application/sdp

v=0
o=- 1314521053 1314521054 IN IP4 216.214.138.230
s=-
c=IN IP4 216.214.138.230
t=0 0
m=image 50164 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy

>> The contact feild is removed just before the Invite is sent to the ITSP
side. Have you configured any sip profiles on the dial-peer that is being
chosen to go out to the ITSP?
002253: May 30 14:17:57.781:
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_change_sdp_line: SDP header
is removed : c=IN IP4 192.168.15.5
002254: May 30 14:17:57.781:
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_change_sdp_line: SDP header
is removed : c=IN IP4 192.168.15.5


>> The Invite is sent to the ITSP with the m=image line, but NO contact field.
002257: May 30 14:17:57.785: //271/AD9029000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:7161112222@192.168.15.20:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.15.5:5060;branch=z9hG4bK5E175E
From: <sip:96251077@192.168.15.5>;tag=384BE4-2088
To: "TCA Fax"
<sip:7161112222@192.168.15.20>;tag=210194~c3f8e039-a60d-49fe-ad79-ee16ee9de7ac-
30639925
Date: Fri, 30 May 2014 18:17:57 GMT
Call-ID: ad902900-3881cb43-136c-140fa8c0@192.168.15.20
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2911906048-0000065536-0000001197-0336570560
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1401473877
Contact: <sip:96251077@192.168.15.5:5060;transport=tcp>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 272

v=0
o=CiscoSystemsSIP-GW-UserAgent 3894 8964 IN IP4 192.168.15.5
s=SIP Call
t=0 0
m=image 16428 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

>> We then get a 488 from the ITSP and this causes the call to disconnect. This
488 is passed to the CUCM from the CUBE. In what case did you see the 488
coming from the CUCM?
002263: May 30 14:17:57.785: //271/AD9029000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/TCP 192.168.15.5:5060;branch=z9hG4bK5E175E
From: <sip:96251077@192.168.15.5>;tag=384BE4-2088
To: "TCA Fax"
<sip:7161112222@192.168.15.20>;tag=210194~c3f8e039-a60d-49fe-ad79-ee16ee9de7ac-
30639925
Call-ID: ad902900-3881cb43-136c-140fa8c0@192.168.15.20
CSeq: 101 INVITE
Content-Length: 0

I looked and had the following in my sip profile attached to my 'voice service voip' section:

voice class sip-profiles 1000
 request ANY sdp-header Connection-Info remove 
 response ANY sdp-header Connection-Info remove

Removing that seems to have made it work with my initial test. Below is the results of a 'show call history fax'. Does this look like it went through using a true T38 call? Any idea why I had those header removals? I will need to check with my vendor to see why they put that in there.

 

show call history fax
Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
Total call-legs: 1


GENERIC:
SetupTime=239468790 ms (10:30:34.647 ESD Mon Jun 2 2014)
Index=136
PeerAddress=
PeerSubAddress=
PeerId=999011
PeerIfIndex=31
LogicalIfIndex=13
DisconnectCause=10
DisconnectText=normal call clearing (16)
ConnectTime=239468790 ms (10:30:34.647 ESD Mon Jun 2 2014)
DisconnectTime=239527320 ms (10:31:33.177 ESD Mon Jun 2 2014)
CallDuration=00:00:58 sec
CallOrigin=2
ReleaseSource=1
ChargedUnits=0
InfoType=fax
TransmitPackets=654
TransmitBytes=67830
ReceivePackets=964
ReceiveBytes=154240
TELE:
ConnectionId=[0x4ADC868D 0xE99911E3 0x81B18B9B 0x6745974A]
IncomingConnectionId=[0x4ADC868D 0xE99911E3 0x81B18B9B 0x6745974A]
CallID=16528
Port=0/1/1 (16528)
BearerChannel=0/1/1
TxDuration=1490 ms
VoiceTxDuration=1490 ms
FaxTxDuration=0 ms
FaxRate=14400 bps
FaxRelayMaxJitterBufDepth=600 ms
FaxRelayJitterBufOverFlow=0
FaxRelayRecentHSmodulation=V.17/short/14400
FaxRelayNumberOfPages=1
FaxRelayTxPaks=465
FaxRelayRxPaks=260
FaxRelayInitHSmodulation=V.17/short/14400
FaxRelayDirection=Transmit
FaxRelayPktLossConceal=0
FaxRelayEcmStatus=Disabled
FaxRelayEncapProtocol=T.38 (UDPTL)
FaxRelayFaxSuccess=Success
 SG3 Fax CM Suppression Type=NONE
NoiseLevel=-69
ACOMLevel=3
SessionTarget=
ImgPages=0
CallerName=
CallerIDBlocked=False
LongDurationCallDetected=no
LongDurCallTimeStamp=
LongDurCallDuration=
OriginalCallingNumber=
OriginalCallingOctet=0x0
OriginalCalledNumber=
OriginalCalledOctet=0x80
OriginalRedirectCalledNumber=
OriginalRedirectCalledOctet=0x0
TranslatedCallingNumber=
TranslatedCallingOctet=0x0
TranslatedCalledNumber=
TranslatedCalledOctet=0x80
TranslatedRedirectCalledNumber=
TranslatedRedirectCalledOctet=0x0
DSPIdentifier=0/1:1
MlppServiceDomainNW=0 (none)
MlppServiceDomainID=0
PrecedenceLevel=-1 (PRECEDENCE_LEVEL_NONE)

 

That output looks fine to me. Receiving the test page on the other side with complete integrity means everything's working ok.

You will need to speak to your vendor about that sip profile. I'm not sure why one would want to remove the connection information from the SDP. It is an important field which tells the other side where to send the media! Even if there is more than 1 instance of the connection field, it's alright. It has to be there for the other side to process the sdp correctly.

Sreekanth Narayanan
Cisco Employee
Cisco Employee

That output looks fine to me. Receiving the test page on the other side with complete integrity means everything's working ok.

You will need to speak to your vendor about that sip profile. I'm not sure why one would want to remove the connection information from the SDP. It is an important field which tells the other side where to send the media! Even if there is more than 1 instance of the connection field, it's alright. It has to be there for the other side to process the sdp correctly.

 

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: