trouble with cisco GW and third-party T.38 fax

[Richard Piskac]

Hello,

i'm testing bladeware vs. cisco gw. If i try fax trough t.37 all is fine. But if i send fax through t.38, i have trouble with ports.
First is opened RTP stream and then is negotiated fax transmition with t38. All is fine, but my gw chose new port for this communication stream, send it in SDP(packet no.481) to the fax machine, but is still listening on the old port for t38. Every time if fax machine try to communicate to the new port recieve message with destination unreachable.

I have pcap from bladeware and detail sip log from cisco gw. Can you help me?
I tried more ios, last was 12.424T4. But nothing.

Thanks. Richard

[Richard Piskac]

Bax is still not working but i try explain my trouble with more detail.

Site A is BladeWare.

Site B is Cisco GW 2811.

A -----invite T38,g711----------> B

.

.

A<------------200Ok---------------- B

RTP chanell is open port on side A is 49152, side B 18432

A<-----------invite T38------------- B reinvite connection to T38, in SDP is m:image 18432 udptl t38

.

A--------------200Ok--------------> B in SDP send parametr m:imate 49152 udptl t38

For this time i think that chanel for T38 must be on src ports for side A: 49152 and for side b 18432, site A has same opinion like me. All T38 communication is from src port 4152 and dst port is 18432, but my cisco GW sends all packet from src port 17716(for actual logs). And for packets from side A with dst port 18432 reply with destination port unreachable.

Some packets are change between sides and then side A send bye. Comunication is ending correctly, but no t38 transmission.

On my GW is trivial configuration. No fallback, fax protocol T38 and G711 codec. Has anybody any idea where is the bug?

Thank.

Risa

[Richard Piskac]

We solved it. I think that it is not the best solution, but fax is working.
The solution is simple. Originating fax in the first message send message and offer only G711. But is capable to accepted T38. My GW after corect setting RTP stream begin with re-invite session to T38 and all works fine.
No port's mistakes...

[amitkumarp]

Hi Richard,

It seems I have the same issue. But in my case I am using H.323 between Fax Server and my Gateway. I am able to send fax but unable recieve them.

Can you send me some example configuration of dial-peers so that I can recieve Fax to My fax server. i am using RightFax Fax Server but is in support from Cisco.

Regards,

Amit.

[dksingh]

Pl. try this...

voice service voip
  h323

     h245 tunnel disable  <-- enter this

[amitkumarp]

Hi Dilip,

I have already entered that command. Are you using SR140 with your Fax Server?? I wanted to know if any configuration needs to be done on Fax Server for Incoming Faxes?? Because from my debugs it seems GW is unable to communicate with Fax Server and unable to establish TCP connection.

Regards,

Amit.

[Richard Piskac]

Hi,

i haven't practise with RightFax, but  here is configuration of my dial-peers:
dial-peer voice 702 pots
description >>incoming from PSTN <<
incoming called-number 90
direct-inward-dial
!
dial-peer voice 703 voip
description >> outgoing to the FAX server <<
destination-pattern 90
session protocol sipv2
session target ipv4:192.168.254.212
codec g711alaw
fax-relay ecm disable
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
no vad
!

And i remember, that we had 1 more mistake in the configuration of fax server. T38 on cisco fax GW support only UDP protocol. We had wrong settings in the fax server for  incoming fax.

Richard

[amitkumarp]

Hi Richard,

Thanks for your inputs.

Well what was that setting which you changed on Fax Server? Because it seems I have done the same mistake as GW is unable to establish connection with Fax Server and I can see it is trying establish TCP connection even though I have applied command "session transport udp" on Dial-peer as well as in "voice service voip". But yead Fax Server is able to establish connection with GW.

I am using H.323 GW so dial-peer is according to it. I haven't disable Fax-relay ecm. What does it stands for?? Is this command necessary?

Thanking you in anticipation.

Regards,

Amit.

[Richard Piskac]

Hi,

i haven't much information about fax server, becouse is not under my support. But i remember, that we were solving trouble with UDP and ports.

But i think that if you are using H.323, for first time GW must build RTP flow with TCP. Through this flow GW send fax tone to the fax server and then renegotiate flow to the T.38. This new flow must be only in UDP.

You must be able make a call between end points and after that you can try fax transmission. If you have possibility try this.

Disable ecm is recomended for dial peers handling fax relay traffic on known lossy networks. I think that you don't need use this command.

Richard

[Steven Holl]

But i think that if you are using H.323, for first time GW must build RTP flow with TCP

This isn't true.  RTP is never sent via TCP.  For H323, we use TCP/1720 for call signaling, and an ephemeral TCP port for H.245 media negotiation.  But the RTP ports negotiated will always be UDP ports.

Back to the issue at hand, though:

In the packet capture the customer attached, the call is connecting, and it is triggering a protocol-based T.38 switchover.

It looks like the issue is that the original INVITE has two m-lines--one for audio and one for t38.  The gateway is okay with this and in the return SDP sets the image port to 0 and has a real audio port.  This is correct behavior.

On the gateway-triggered re-invite, we only send a m-line for T.38.  Since the original call had two media streams in the SDP, as per RFC 3264, it is a spec violation to drop one of the m-lines.  During this switchover, I think the gateway needs to be populating the t38 port, and setting the audio m-line port to 0 to signal that the audio stream is going away.  This looks like an IOS specification violation to me.

I'm going to contact our SIP developers and see if I can get any further on this specific behaior.  If I get an answer, I will try to remember and update this thread.  For what it is worth, I haven't seen much of our stuff handle multiple m-lines well yet.  I know CM has issues with it, too.

There is some talk about how multiple m-line behavior should act here:

http://www.mail-archive.com/sip-implementors@cs.columbia.edu/msg16006.html

And some suggestions with sample examples here:

http://tools.ietf.org/html/rfc4317#section-3.2

For the OP: Can you get your software to not send the m=image line for T.38 in the original outbound INVITE's SDP?  That should workaround this issue.

On the same topic (but not the OP's issue): I know RF sends two m-lines (one for u-law and one for a-law) in some versions.  This will cause a t.38 re-invite thrashing scenario.  This can be disabled in recent versions with the below procedure:

In the  configuration tool, in advanced mode, highlight the IP call control  stack that you are using in the left pane, ( SIP or H323 )

Click on RTP parameters in the right pane, there is a drop down for the RTP codec list.  simply remove pcma and leave pcmu.
make sure that there is no spaces after pcmu.

Save and then apply. SDP offering after this should only reflect pcmu offering.

[Steven Holl]

I heard back from development.  The re-invite for T38 with only one m-line is, like I suspected, a specification violation.

I'm going to try and set this up in my lab with sipp and see if I can reproduce it on the latest IOS interim.  If I can, I'll file a bug for this behavior and report back here with the bug ID.

UPDATE: I tested this in my lab and I can't reproduce the issue in the latest interim.  It looks like 15.1(3)T won't have the issue when it is released.  I don't have time to test previous versions, but I can say that if anyone is seeing multiple m-line issues in mid-call re-invited, try 15.1(3)T which should be released fairly shortly.

Message was edited by: Steven Holl