Solved: UC520 T.38 Fax Relay Testing Verification

bbbowden1013 · ‎10-26-2011

I am trying to test T.38 fax relay functionality with a UC520. The faxes are completing successfully but I can't tell if they are using the voice codec or they are being completed using T.38.

I have tried show call history fax but all it shows is "0" for all values.

Does anyone know how to determine which codec is being used?

Thanks.

ADAM CRISP · ‎10-26-2011

Hi Brett,

You can type in on CLI, when your fax is transmissing

show call active voice compact

You should see something like :

68097024 ANS FAX T45 t38 VOIP P+441869222500 X.X.X.X:XXXX

If you see g711ulaw / g711alaw instead of t38 - you're not doing t38

Adam

View solution in original post

ADAM CRISP · ‎10-26-2011

Hi Brett,

You can type in on CLI, when your fax is transmissing

show call active voice compact

You should see something like :

68097024 ANS FAX T45 t38 VOIP P+441869222500 X.X.X.X:XXXX

If you see g711ulaw / g711alaw instead of t38 - you're not doing t38

Adam

bbbowden1013 · ‎10-26-2011

Adam,

That was it exactly. Unfortunately, it is showing g711ulaw. Now I have to figure out why it isn't switching over to t38

Brett.

ADAM CRISP · ‎10-26-2011

Does the service provider support T38 ?

It's common for the initial call to start as normal audio. One end *normally* (based on my debugging t.38 on lots of kit) the receiving end detects the fax tones and sends a SIP re-invite back offering T.38. Hopefully the T38 re-invite is accepted, t.38 re-negotiated and all is good.

You could debug ccsip messages and have a look at this to see whether this is happening.

Have you T.38 enabled on your UC ?

example on outgoing dial-peer:

fax-relay ecm disable

fax nsf 000000

fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback pass-through g711alaw (you'll want u-law I expect)

no vad

You can also set the fax protocol stuff globally under voice service voip

Good luck.

Adam

In my experiance *normally* (based on my debugging t.38 on lots of kit) the receiving party UA detects

bbbowden1013 · ‎10-26-2011

Adam,

Yes, I enabled T.38 on my UC and I talked to our SIP provider and they said they support T.38 but we are using Nexvortex. They bill themselves as a SIP signalling company and hand off your traffic to the closest partner. I'm wondering if the problem is with that partner.

My test configuration has been:

Fax server -> Modem -> FXS port on UC -> SIP trunk to Nexvortex dialing another fax machine we have connected to PSTN.

Is this a valid test? I'm not controlling both ends of the SIP session so is that where my problem might lie?

Thank you for the help.

Brett.

ADAM CRISP · ‎10-26-2011

Hi,

Yes completely valid.

capture the output of show ccsip messages when you make your fax call and we can see whether your SP sends you the t.38 re-invite. But I'm not sure there's a lot you can do about it. Are your non-t38 faxes working ?

Adam

bbbowden1013 · ‎10-26-2011

Adam,

Yes, non T.38 faxes are working fine for this test environment but we have a client that is using satellite as their internet/voip connection. Because of the cost of satellite bandwidth, we are using the g729 codec which doesn't play well with faxes.

So, I've been given the task of figuring out how to make this work.

I did find something interesting in the ccsip messages debug. If I'm reading this right, it looks like t38 is being offered from my end, but I'm getting a "Bad Request" back. Any idea what "Missing required SDP header 'c='" means?

Thanks,

Brett.

034630: Oct 26 12:29:17.788: //5700/327C0BA7B433/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:1XXX755XXXX@68.68.116.55:5060 SIP/2.0
Via: SIP/2.0/UDP 2XX.1XX.2XX.1XX:5060;branch=z9hG4bKC60106C
From: "Computer Fax" <18887XX1XX>;tag=1ABFAA90-17D6
To: <1XXX755XXXX>;tag=gK028a6c52
Date: Wed, 26 Oct 2011 18:29:17 GMT
Call-ID: 33CE316D-FF3711E0-B438ACFF-DE2DBA44@2XX.1XX.2XX.1XX
Route: <1XXX755XXXX>,<206.80.67.68:5060>

Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0846990247-4281799136-3023285503-3727538756
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 104 INVITE
Max-Forwards: 70
Timestamp: 1319653757
Contact: <18887XX1XX>
Expires: 180
Allow-Events: telephone-event
Proxy-Authorization: Digest username="username",realm="nexvortex.com",uri="sip:1XXX755XXXX@68.68.116.55:5060",response="797cfdfc9076ec9a3450c3102c1cc73a",nonce="4ea85296311d5edcc85529e701f3061c418752ba",algorithm=md5
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Length: 355

v=0
o=CiscoSystemsSIP-GW-UserAgent 3112 18282 IN IP4 2XX.1XX.2XX.1XX
s=SIP Call

t=0 0
m=image 18976 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy

034631: Oct 26 12:29:17.896: //5700/327C0BA7B433/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 2XX.1XX.2XX.1XX:5060;branch=z9hG4bKC60106C;rport=62142
From: "Computer Fax" <18887XX1XX>;tag=1ABFAA90-17D6
To: <1XXX755XXXX>;tag=gK028a6c52
Call-ID: 33CE316D-FF3711E0-B438ACFF-DE2DBA44@2XX.1XX.2XX.1XX
CSeq: 104 INVITE
Server: nVSIP 12.02.01
Content-Length: 0

Received:
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 2XX.1XX.2XX.1XX:5060;rport=62142;branch=z9hG4bKC60106C
From: "Computer Fax" <18887XX1XX>;tag=1ABFAA90-17D6
To: <1XXX755XXXX>;tag=gK028a6c52
Call-ID: 33CE316D-FF3711E0-B438ACFF-DE2DBA44@2XX.1XX.2XX.1XX
CSeq: 104 INVITE
Error-Info: <1XXX755XXXX>;cause="Missing required SDP header 'c='"
Content-Length: 0

034634: Oct 26 12:29:18.028: //5700/327C0BA7B433/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:1XXX755XXXX@68.68.116.55:5060 SIP/2.0
Via: SIP/2.0/UDP 2XX.1XX.2XX.1XX:5060;branch=z9hG4bKC60106C
From: "Computer Fax" <18887XX1XX>;tag=1ABFAA90-17D6

To: <1XXX755XXXX>;tag=gK028a6c52
Date: Wed, 26 Oct 2011 18:29:17 GMT
Call-ID: 33CE316D-FF3711E0-B438ACFF-DE2DBA44@2XX.1XX.2XX.1XX
Route: <1XXX755XXXX>,<206.80.67.68:5060>
Max-Forwards: 70
CSeq: 104 ACK
Allow-Events: telephone-event
Content-Length: 0

ADAM CRISP · ‎10-26-2011

I don't thing the SP is liking T38!

Would Fax -> email be an option at the remote site ?

bbbowden1013 · ‎10-26-2011

Yeah, that is another option but T.38 SEEMS so simple and would only require us to configure the client's UC. I'm going to go back to Nexvortex and do some more troubleshooting with them.

I appreciate all the assistance.

Brett.

ADAM CRISP · ‎10-26-2011

Brett, What you're trying to get to work is very very interesting, but I also think there are probably a relatively limited number of people about who have gone through testing t38 over an 8kb codec and when cross referenced with the listeners of the UC500 forum are probably close to zero. If anybody disagrees jump on!

Has the client a head office with another Cisco UC? I'm wondering whether you could try:

remote fax -> remote UC > t38/g729 fax rate 7200 -> local UC > SIP Trunk breakout inband || t38 -> PSTN

But I've not researched the fax interworking features of the CUBE product. I'm wondering whether you should ask Cisco?

Good luck with this.

bbbowden1013 · ‎10-26-2011

Adam,

Looking back through the entire debug, when the initial invite is sent, the c= header is there. It is only when the re-invite is sent to try to establish the t38 session that the c= header goes missing. I'm going to take a guess that when Nexvortex ever gets back to me, that they are going to say that it is a Cisco problem, i.e. the Cisco SIP Gateway isn't providing all the required information and therefore is a configuration issue.

Have you ever gotten a UC520 to work using t38?

Thanks,

Brett.

ADAM CRISP · ‎10-26-2011

Yes t.38 Fax is fine on UC520's.

Interoperability issue ?

The re-invite you're sending is offering some T38 parameters for negotiation. At this point in time you are not wanting to amend the existing media flow incase T38 is not supported by the remote end... -( which is working as your faxes are working inband.)

Adam

ADAM CRISP · ‎10-26-2011

Having said that, I've just had a look over here and my test does include the connection line.

If you have the time I'd be interested in seeing your trace. I can't give this any more time tonight though -will be Friday.

Adam

bbbowden1013 · ‎10-26-2011

Adam,

Again, I really appreciate all info and help. I'd be more than happy to share what ever you'd like to look at but I'm not sure what you mean by "trace"

Thanks,

Brett.

ADAM CRISP · ‎10-26-2011

Output of ccsip messages starting from initial invite.

On my tests between Ciscos it's always the receiving gateway that kicks off the t38 negotiation, and yes there's a c line. I've asked a colleague about the legitimacy of having this missing - not that this helps you much.

Sent from Cisco Technical Support iPhone App