UC520 T.38 Fax Relay Testing Verification

[bbbowden1013]

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.

[bbbowden1013]

I just got a response back from Nexvortex and they are looking into it from their end as well.  I'll sanitize the entire trace (I will have to run it again so it won't be exactly the same) and post it tomorrow.

Thanks,

Brett.

[ADAM CRISP]

Hi Brett

Confirmation:

RFC4566 Section 5.7 2nd paragraph:

   A session description MUST contain either at least one "c=" field in

   each media description or a single "c=" field at the session level.

   It MAY contain a single session-level "c=" field and additional "c="

   field(s) per media description, in which case the per-media values

   override the session-level settings for the respective media.

Not having a c-line anywhere in the SDP is not permitted.

I don't know where you captured your SIP Invite - If this was provided by the SP, I'd tr-try and capture on your UC520 to make sure the c line is definitely missing. Upgrade your unit - if it is still broken - raise this with TAC.

Adam

[bbbowden1013]

Adam,

That capture was from my UC520, so I'm in the process of getting TAC on the case.

Brett.

[bbbowden1013]

Adam,

I think I have it fixed.  It ended up being a couple of things:

1. We had a sip profile configured:

voice class sip-profiles 1000

request ANY sdp-header Connection-Info remove response ANY sdp-header Connection-Info remove

I don't know where it came from (I didn't configure it), but that was what was removing the 'c=' header.

2. Since Nexvortex is a SIP signalling company, it ends up routing our SIP calls through the closest SIP provider to the end point and that SIP provider is not guaranteed to support T.38.  However, Nexvortex can set up specific routes for a particular ANI, ensuring that a call from a T.38 fax line only goes to SIP providers that support T.38.

Result is, I successfully sent a T.38 fax call through our normal Internet connection.  Next week, I'll have access to our demo satellite equipment and will be able to test this over Satellite.

Again, thanks for the help.

Brett.

[ADAM CRISP]

Was this profile applied in a dial-peer ?

Anyway - sounds like you can have a good weekend.

cheers

[bbbowden1013]

No, it was applied at the voice service voip global level.  I'm not sure why it didn't cause problems throughout our SIP trunk, but according to what I read, you shouldn't even be able to remove connection-ino because that is a required header.  Maybe that is why but only end results matter so I am going to have a good weekend.

Cheers!

[bbbowden1013]

Adam,

Just wanted to update you with the final results of my proof of concept.  I was able to send and receive faxes over a satellite Internet circuit using T.38.  The UC540 I was using for this test was configured to use g729 for voice compression and would not reliably send a fax using passthrough, so all in all, a very successful test.

Again,

Thanks for the help.

Brett.