10-26-2011 09:19 AM - edited 03-21-2019 04:51 AM
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.
Solved! Go to Solution.
10-26-2011 01:39 PM
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.
10-27-2011 04:27 AM
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
10-27-2011 08:10 AM
Adam,
That capture was from my UC520, so I'm in the process of getting TAC on the case.
Brett.
10-28-2011 09:59 AM
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.
10-28-2011 10:41 AM
Was this profile applied in a dial-peer ?
Anyway - sounds like you can have a good weekend.
cheers
10-28-2011 10:46 AM
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!
11-03-2011 01:47 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide