Cisco Cube & T.38 Fax protocol - Call Manager 10.5

Yannick Vranckx · ‎08-25-2014

Hello,

I wish some assistance in finding out an issue: Recently we upgraded a customers call manager from 8.6 to 10.5, the upgrade went smooth. There is 1 issue with the T.38 Fax protocol, we have a Faxination server which handles the faxes to e-mail etc. This is configured towards the call manager, so for the fax number we have a route pattern which is forwarded to a SIP connection that is connected to the Faxination server.

So for example 9999 is a fax number that has a route pattern towards a SIP Trunk to the Faxination server.

This doesn't work anymore on the Call Manager 10.5, the voicegateways are configured as CUBE which have a sip connection to the provider.

I believe the problem is situated on the Cisco Cube and not on the Call Manager: I have traced in wireshark from Call Manager and also from the fax server, there is a T.38 max buffer set of 14000. For a weird reason when the T.38 transmission passes the Cisco CUBE the T.38 max buffer is set towards 200. At first i thought it was the provider but it isn't, it's my own cisco cube that sends it towards the provider causing the fax call to fail.

I can't even call inwards to the fax number; it doesn't dial, it automatically hangs up with a small beep.

For example a trace from the Cisco Cube:

***************************

Received:
INVITE sip:XXXXXXX@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bKac03120ad68f
From: <sip:XXXXXXX@X.X.X.X>;tag=43717~cac1a8e8-91f3-4735-bc48-b68717f25816-46700953
To: <sip:XXXXXXXX@X.X.X.X>;tag=D0EBE408-2387
Date: Mon, 25 Aug 2014 12:47:31 GMT
Call-ID: CF684087-2B8C11E4-B2B0AF09-C66FE7A3@X.X.X.X
Supported: timer,resource-priority,replaces
Cisco-Guid: 3479636023-0730599908-2997530377-3329222563
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence, kpml
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=MIXED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Min-SE: 1800
Remote-Party-ID: <sip:XXXX@X.X.X.X>;party=calling;screen=no;privacy=off
Contact: <sip:XXXX@X.X.X:XXXX>
Content-Type: application/sdp
Content-Length: 360

v=0
o=CiscoSystemsCCM-SIP 43717 2 IN IP4 X.X.X.X
s=SIP Call
c=IN IP4 X.X.X.X
t=0 0
m=image 4012 udptl t38
a=T38FaxVersion:1
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=T38FaxMaxBuffer:14000
a=T38FaxMaxDatagram:1500

********************************************

I have bolded the important parts; This is a trace from the Call Manager to the Cube VoiceGateway, notice that the T38FaxMaxBuffer is set to: 14000

If i continue the trace, there will be a next trace that will send the information from the local Cisco Cube towards the provider:

***********************************************

Sent:
INVITE sip:XXXXXXXX@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK3A902266B
From: <sip:XXXXXXX@X.X.X.X>;tag=D0EBE41C-E5B
To: <sip:XXXXXXXX@X.X.X.X;pstn-params=808382808883>;tag=gK0219eb8c
Date: Mon, 25 Aug 2014 12:47:31 GMT
Call-ID: 687997967_7844794@X.X.X.X
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3479636023-0730599908-2997530377-3329222563
User-Agent: Cisco-SIPGateway/IOS-15.2.3.T
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1408970851
Contact: <sip:XXXXXXX@X.X.X.X:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 326

v=0
o=CiscoSystemsSIP-GW-UserAgent 347 1499 IN IP4 X.X.X.X
s=SIP Call
c=IN IP4 X.X.X.X
t=0 0
m=image 26298 udptl t38
c=IN IP4 X.X.X.X
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

**************************************************************

Here we can see that the Fax Max Buffer has been changed somehow to a value of 200, it came from 14000. So i'm thinking it's something going wrong here. In the wireshark traces i've pulled from Call Manager to the Fax server i can see the perfect SIP setup but ofcourse no RTP stream because it just doesn't happen.

I've been thinking to upgrade the IOS of the router, could that help? Or is this a hidden setting on the Cube that i can adjust. Googling didn't bring me a clear answer.

Kr,

Yannick Vranckx

afmmanicke · ‎08-25-2014

In your voice service voip or the relevant dial-peer do you have "fax protocol t38 version 3" configured? If the version is not specified, version 0 will be configured automatically.

Yannick Vranckx · ‎08-26-2014

yes,

This is configured.

It's stated that cisco cube cannot accept datagrams above 320, and the CUBE changes this himself, on a call manager 8.6 this works but on a call manager 10 it doesn't work.

Manish Prasad · ‎08-26-2014

Yannick,

Is it the buffer causing fax to fail ? What does sip transport layer logs shows when you enable debug ccsip message all ?

I am not sure about any CUBE command that can increase buffer size. It may be depend upon some other command which indirectly relate to buffer size.

Here is one link from Ask the expert , you can try some recommendation mentioned there.

Yannick Vranckx · ‎08-26-2014

Well i can see that the CUBE does not allow above 200 max buffer and 320 data gram size, but the negotiation between the call manager & the faxination server is set to: 14000 max buffer and 1500 data gram size.

The CUBE changes this , this works for the Call Manager 8.6 solution perfect but not for the Call Manager 10, i'm guessing we'll have to locate the answer for the issues around there somewhere. I wasn't able to locate any service parameter or enterprise parameter in correlation with this.

********************************************************

=> From Call Manager to the CUBE

v=0
o=CiscoSystemsCCM-SIP 43717 2 IN IP4 X.X.X.X (Call Manager IP)
s=SIP Call
c=IN IP4 X.X.X.X(CUBE IP)
t=0 0
m=image 4012 udptl t38
a=T38FaxVersion:1
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=T38FaxMaxBuffer:14000
a=T38FaxMaxDatagram:1500

****************************************************

=> This is from our CUBE

v=0
o=CiscoSystemsSIP-GW-UserAgent 347 1499 IN IP4 X.X.X.X (CUBE external IP)
s=SIP Call
c=IN IP4 X.X.X.X (CUBE External IP)
t=0 0
m=image 26298 udptl t38
c=IN IP4 195.130.150.157
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

*************************************************

=> This from our CUBE to the providers SIP ( A sonus it seems)

v=0
o=Sonus_UAC 24038 7437 IN IP4 X.X.X.X => Provider IP
s=SIP Media Capabilities
c=IN IP4 X.X.X.X
t=0 0
m=image 10454 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:176
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv

*********************************************

Everything is the same on a sniffer trace of Call Manager 8.6, exactly the same steps but it does work there and not on 10.5

Yannick Vranckx · ‎08-26-2014

There must be a difference on how call manager 10.X handles T.38 then how call manager 8.6 handles it.

Manish Prasad · ‎08-27-2014

Can you collect call manager traces from RTMT and attach it here.

Yannick Vranckx · ‎08-27-2014

Dear Manish,

I will attach the CM traces asap, in the meantime i've also given them to TAC and i stumbled on this error.

05282886.017 |15:11:05.518 |AppInfo |!!ERROR!! -MediaMLinesList-::getSDPMode, ERROR: Invalid Size or Line Index Size=0, Line Index=0

I'm thinking this error is between the call manager and the CUBE.

Manish Prasad · ‎08-29-2014

I don't think this error is causing fax to fail. We can give a try if you give us traces.

Yannick Vranckx · ‎09-17-2014

Hello Manish,

Uploaded the call manager traces with the recreated issue.

The fax number comes into the call manager via the SIP gateways (CUBE), this are sent to call manager, call manager has a route pattern configured that heads them towards the fax server (faxination), this is done via a SIP trunk.

The issue we are having is that we hear a short beep and then the call is disconnected, i've scouted quick through the trace and i see T.38 invites but also bye's.

When we do the same procedure on the older Call Manager 8.6 the call proceeds as configured and rings like a fax

Kr,

Yannick Vranckx

Manish Prasad · ‎09-18-2014

I have looked at traces and few things i want to know.

1. Which codec negotiates when you test using CUCM 8.6 ?

In the attached traces for CUCM 10 Alaw is negotiated before the fax INVITE. If there is difference in both CUCM cases , then please add only Ulaw on the outbound dial-peer towards CUCM.

2. Faxation server is sending BYE message, so most probably its not liking some parameters send by CUBE and relayed by CUCM.

Can you look at faxation server logs and see if anything you can find in there. And i cant find anything in traces which points issue with CUCM.

Does CUBE also modify max-buffer and datagram size when you use CUCM 8.6 ?

Yannick Vranckx · ‎09-19-2014

Dear Manish,

Attached the traces of the 8.5 call manager, i've started testing at timestamp 12:45. With calling number 27551617 and called number 8825 internal.

I can't seem to locate the codec used in the communications between Faxination&Call manager here

Yannick Vranckx · ‎09-19-2014

Manish,

I did notice something, when i just open a wireshark trace, i can clearly see that when i dial a fax that will fail ( connected to CM10) it clearly states on a RTP string (G711PCMA)

When i try it again with a fax that does work, it will state (G711PCMU) in the RTP packet (On Call manager 8.6)

Kind Regards,

Yannick Vranckx

Yannick Vranckx · ‎09-22-2014

Manish

Both wireshark traces reveal the difference in Codec

The CUCM 10.5 negotiates G711a (This fax doesn't proceed)

The CUCM8.5 negotiates G711u ( This fax proceeds)

Can we fix the codec on CUCM 10 at G711ulaw? This is communication between CUCM & Faxination

Manish Prasad · ‎09-24-2014

Sorry for the delay in reply. I don't know how i missed email notifications.

I went through CCM8.5 traces. Here are findings

1. Call leg between CUCM8.5 to faxation server negotiated to use Ulaw codec. (Bcoz MTP is enabled on the sip trunk with MTP Preferred Originating Code set to Ulaw ). And also you verified it through wireshark.

2. CUBE do modify max-buffer and datagram size with this CUCM aswell , so its not an issue with fax datagram and buffer size.

To enable G711Ulaw codec, here is your options.

1. Enable MTP on CUCM 10 SIP trunk with Originating codec set as Ulaw.

2. Set only "codec g711ulaw" under CUBE dial-peer which is pointing towards CUCM. (You can check it by enabling debug voice ccapi inout).

3. Use Audio Codec Preference list.