cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2114
Views
0
Helpful
1
Replies

GFI Fax Maker with Cisco VGW T38 faxing problem

Greetings,         

     We have implemented the GFI fax maker solution using  brooktrout SR140-L driver which should send and receive faxes through a Cisco voice gateway 2901 router using T38 fax protocol, my environment has a SIP Trunk connection with the provider for carrying external calls (actually it can be considered a VoIP connection using SIP protocol with the provider), the connection between the Cisco VGW and the fax server is also through SIP dial peer.

We can send faxes successfully from the fax server to the Cisco VGW to the PSTN but the problem is that we cannot receive faxes on the SIP line as the line open and the call is answered then the fax parameters handshaking is failed and the call is terminated.

We have contacted the fax server vendor and we have gone through a lot of troubleshooting with them which ends up with the following reply from their side:

The reason this is not working is because SR140 finds no common codec. The Cisco is answering the T.38 switch request with a bad SDP:

[...]

Media Description, name and address (m): image 17232 udptl t38

Connection Information (c): IN IP4 172.16.61.250

Media Attribute (a): inactive

Media Attribute (a): rtpmap:8 PCMA/8000

Media Attribute (a): ptime:20

Media Attribute (a): T38FaxVersion:0

[...]

The three bolded lines should not be there. Technically, you cannot have media attributes from another codec creep into another codec's media description. Here it looks like the attributes for G.711A are inserted in the middle of the attributes for the T.38 stream. In effect, we want G.711 to be silenced (a=inactive), but those attributes are simply in the wrong place.

Please submit this to Cisco to get some input on what to rectify in the configuration

I have attached some related logs including the following:

1.    The network setup with IP Addresses.

2.    Cisco router fax related configurations.

3.    Cisco VGW Router Sh tech.

4.    Debug output from the VGW for the “debug voice ccapi inout” and “debug ccsip messages” commands during a failed coming fax call knowing that        the calling number is 138471627 and the called number is 8459410 which translated later to 9410 then sent to the fax server.

5.    Wireshark Captured data from fax server for the same failed incoming fax call which shows the communication nature between the fax server and the VGW and the exchanged messages.

So based on all these inputs I need to know how the VGW T38 faxing configurations should be tuned to be able to communicate properly with the fax server.

Thanks in advance.

1 Reply 1

Karthik Sivaram
Level 4
Level 4

Hello Ahmed,

I looked at the debugs you attached . Looks like the fax server is sending you  2  m lines in the Re - invite for the switchover  ...

Received:

INVITE sip:138471627@172.16.61.250:5060 SIP/2.0

From: <9410>;tag=9081340-0-13c4-55013-957c9-6e9c2524-957c9

To: <138471627>;tag=1162E74-1EEA

Call-ID: 82A35188-9EF911E3-88DBA697-332EF2EB@172.16.61.250

CSeq: 1 INVITE

Via: SIP/2.0/UDP 172.16.8.47:5060;branch=z9hG4bK-957cc-247ef54f-7edc608a

Supported: 100rel

Max-Forwards: 70

User-Agent: Brktsip/6.6.0B2 (Dialogic)

Contact: <172.16.8.47>

Content-Type: application/sdp

Content-Length: 348

v=0

o=- 2209784077 0509543000 IN IP4 172.16.8.47

s=no_session_name

t=0 0

m=audio 0 RTP/AVP 8 101               <=====

c=IN IP4 172.16.8.47

a=fmtp:101 0-15

m=image 56032 udptl t38               <=====

c=IN IP4 172.16.8.47

a=T38FaxVersion:0

a=T38MaxBitRate:14400

a=T38FaxRateManagement:transferredTCF

a=T38FaxMaxBuffer:200

a=T38FaxMaxDatagram:72

a=T38FaxUdpEC:t38UDPRedundancy

Cisco IOS GWs are compliant with RFC  3264 (Offer/Answer Model with the SDP). Here is a snippet from RFC 3264 (Offer/Answer Model with the SDP)

"

6 Generating the Answer

For each "m=" line in the offer, there MUST be a corresponding "m="

  line in the answer.  The answer MUST contain exactly the same number

  of "m=" lines as the offer.  This allows for streams to be matched up

  based on their order.  This implies that if the offer contained zero

  "m=" lines, the answer MUST contain zero "m=" lines."

https://www.ietf.org/rfc/rfc3264.txt

Therefore the fax call is failing as the intial INVITE sent by the IOS GW contained just one m line but in the Re invite it is recieving 2 m lines.

An enhancement request for this behaviour was raised  in CSCsi10343  .

Hope this helps!

Regards,

Karthik Sivaram

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: