asterisk users - Mar 2009 - Sending faxes with T.38 problem. Asterisk - 1.6.0.6

Hello,

I'm having difficulties to make Asterisk (1.6.0.6) interoperate correctly
with a CISCO mediaGW in order to send faxes to the PSTN using T.38.

When Asterisk sends the initial INVITE containing the T.38 media offer in
the SDP, the CISCO answers with a 488 Not Acceptable Media.
Apparently, it looks like a configuration problem in the CISCO, but I have
tested the CISCO with the Zoiper client and it successfully sends faxes. The
only difference I have noticed between the Asterisk and Zoiper is that
whereas the Asterisk sends the T.38 SDP information in the initial INVITE,
Zoiper establishes a voice call first and then re-negotiates(with a
re-INVITE) the session in order to send the T.38 media.
Is it possible to make Asterisk work like this? or is this a problem in the
configuration of the CISCO? Any ideas?

Thanks in advance.

Regards,

Santi


**The call-file I'm using is:

Channel: SIP/080999999999 at outbound-calls
MaxRetries: 3
WaitTime: 30
Set: LOCALSTATIONID=22222
Set: LOCALHEADERINFO=T38 fax
Set: T38CALL=1
Set: T38TXDETECT=yes
CallerID: 22222
Context: fax-out
Extension: 22222
priority:1


My sip.conf file is:

sip.conf
[general]
bindport=5060                   ; UDP Port to bind to (SIP standard port is
5060)
bindaddr=192.168.222.160        ; IP address to bind to (0.0.0.0 binds to
all)
domain=192.168.222.160          ; Add IP address as local domain

t38pt_udptl=yes

[outbound-calls]
type=friend
context=openser
allow=all
;dtmfmode=info
host=10.100.222.201
insecure=very
canreinvite=no
pedantic=no
call-limit=10

The extensions.conf file

[fax-out]
exten =>s,1,Set(FAXFILE=/root/santi/fax/prueba.tif)
exten =>s,n,SipDTMFMode(inband)
exten =>s,n,SendFax(${FAXFILE})
exten =>s,n,Hangup


The SIP trace is:


INVITE sip:0809999999 at 10.100.222.201 <sip%3A0809999999 at
10.100.222.201>SIP/2.0
Via: SIP/2.0/UDP 192.168.222.160:5060;branch=z9hG4bK306b777c;rport
Max-Forwards: 70
From: "22222" <sip:22222 at 192.168.222.160 <sip%3A22222 at
192.168.222.160>
>;tag=as43e12927
To: <sip:0809999999 at 10.100.222.201 <sip%3A0809999999 at
10.100.222.201>>
Contact: <sip:22222 at 192.168.222.160 <sip%3A22222 at
192.168.222.160>>
Call-ID: 4f9fb8387458a3c6205e2c4467e48ad2 at 192.168.222.160
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.0.6
Date: Tue, 10 Mar 2009 11:29:44 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 290

v=0
o=root 525135648 525135648 IN IP4 192.168.222.160
s=Asterisk PBX 1.6.0.6
c=IN IP4 192.168.222.160
t=0 0
m=image 4222 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:400
a=T38FaxUdpEC:t38UDPFEC

#
U +0.015757 10.100.222.201:5060 -> 192.168.222.160:5060
SIP/2.0 488 Not Acceptable Media
Reason: Q.850;cause=65
Date: Tue, 10 Mar 2009 11:29:18 GMT
From: "22222" <sip:22222 at 192.168.222.160 <sip%3A22222 at
192.168.222.160>
>;tag=as43e12927
Allow-Events: telephone-event
Content-Length: 0
To: <sip:0809999999 at 10.100.222.201 <sip%3A0809999999 at
10.100.222.201>
>;tag=417D2718-582
Call-ID: 4f9fb8387458a3c6205e2c4467e48ad2 at 192.168.222.160
Via: SIP/2.0/UDP 192.168.222.160:5060;branch=z9hG4bK306b777c;rport
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 INVITE


#
U +0.000164 192.168.222.160:5060 -> 10.100.222.201:5060
ACK sip:0809999999 at 10.100.222.201 <sip%3A0809999999 at 10.100.222.201>
SIP/2.0
Via: SIP/2.0/UDP 192.168.222.160:5060;branch=z9hG4bK306b777c;rport
Max-Forwards: 70
From: "22222" <sip:22222 at 192.168.222.160 <sip%3A22222 at
192.168.222.160>
>;tag=as43e12927
To: <sip:0809999999 at 10.100.222.201 <sip%3A0809999999 at
10.100.222.201>
>;tag=417D2718-582
Contact: <sip:22222 at 192.168.222.160 <sip%3A22222 at
192.168.222.160>>
Call-ID: 4f9fb8387458a3c6205e2c4467e48ad2 at 192.168.222.160
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.0.6
Content-Length: 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20090310/2ff53883/attachment.htm

On Tue, Mar 10, 2009 at 10:27 AM, Santiago Gimeno
<santiago.gimeno at gmail.com> wrote:
> Hello,
>
> I'm having difficulties to make Asterisk (1.6.0.6) interoperate
correctly
> with a CISCO mediaGW in order to send faxes to the PSTN using T.38.
> Is it possible to make Asterisk work like this?
yes, as I've done it, although with 1.6.0.5
>or is this a problem in the  configuration of the CISCO?
Could be. Would you post the Cisco config relevant to this?
>Any ideas?
> **The call-file I'm using is:
>
> Channel: SIP/080999999999 at outbound-
> calls
> MaxRetries: 3
> WaitTime: 30
> Set: LOCALSTATIONID=22222
> Set: LOCALHEADERINFO=T38 fax
> Set: T38CALL=1
> Set: T38TXDETECT=yes
> CallerID: 22222
> Context: fax-out
> Extension: 22222
> priority:1
A call file that works for me is:
Channel: SIP/287 at system.im.faxing.to
MaxRetries: 2
RetryTime: 15
WaitTime: 15
Set: FAXMODE=T38
Set: REMOTESTATIONID=System Faxing test
Application: SendFAX
Data: /path/to/the/file.tif

----- "Santiago Gimeno" <santiago.gimeno at gmail.com> wrote:
> Hello,
> 
> I'm having difficulties to make Asterisk (1.6.0.6) interoperate
> correctly with a CISCO mediaGW in order to send faxes to the PSTN
> using T.38.
> 
> When Asterisk sends the initial INVITE containing the T.38 media offer
> in the SDP, the CISCO answers with a 488 Not Acceptable Media.
> Apparently, it looks like a configuration problem in the CISCO, but I
> have tested the CISCO with the Zoiper client and it successfully sends
> faxes. The only difference I have noticed between the Asterisk and
> Zoiper is that whereas the Asterisk sends the T.38 SDP information in
> the initial INVITE, Zoiper establishes a voice call first and then
> re-negotiates(with a re-INVITE) the session in order to send the T.38
> media.
> Is it possible to make Asterisk work like this? or is this a problem
> in the configuration of the CISCO? Any ideas?
The issue here is receiving T38 in the initial INVITE of the incoming call.
Right now
this causes the entire leg to be negotiated with T38, and the subsequent
outgoing INVITE
to also get sent with only T38.

This was filed as an issue and is being tracked at
http://bugs.digium.com/view.php?id=12437. Thus far
I have created a branch for Asterisk 1.4 that changes the behavior to accept the
incoming INVITE with
either audio and T38, or only T38 (if we only got T38). The outgoing call
initially goes out as audio until
T38 kicks in and it is reinvited to T38. This seems to work the best.

Since you are using 1.6.0 I will make some time to create a branch with the
changes in it based off of 1.6.0 so
I can get further testing.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

----- "Santiago Gimeno" <santiago.gimeno at gmail.com> wrote:
> 
> **The call-file I'm using is:
> 
> Channel: SIP/080999999999 at outbound-
> calls
> MaxRetries: 3
> WaitTime: 30
> Set: LOCALSTATIONID=22222
> Set: LOCALHEADERINFO=T38 fax
> Set: T38CALL=1
> Set: T38TXDETECT=yes
> CallerID: 22222
> Context: fax-out
> Extension: 22222
> priority:1
> 
And upon further examination... don't put T38CALL in as a variable. It will
cause the initial INVITE to only
have T38. Leave it out and things should hopefully reinvite.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

On Tue, Mar 10, 2009 at 11:18 AM, Joshua Colp <jcolp at digium.com>
wrote:
> ----- "Santiago Gimeno" <santiago.gimeno at gmail.com>
wrote:
> This was filed as an issue and is being tracked at
http://bugs.digium.com/view.php?id=12437. Thus far
> I have created a branch for Asterisk 1.4 that changes the behavior to
accept the incoming INVITE with
> either audio and T38, or only T38 (if we only got T38). The outgoing call
initially goes out as audio until
In that case, Santiago should change the
canreinvite=no

to
canreinvite=yes

reload sip
and see if that improves things.

Thanks for the responses.

I have solved the problem by using a different tiff generator. I used the gs
command:

# gs -q -sDEVICE=tiffg3 -dSAFER -dNOPAUSE -sOutputFile=test.tif test.pdf

Best regards,

Santi



On Thu, Mar 12, 2009 at 3:30 PM, David Backeberg <dbackeberg at
gmail.com>wrote:
> On Wed, Mar 11, 2009 at 7:32 AM, Santiago Gimeno
> <santiago.gimeno at gmail.com> wrote:
> > I finally solved the issue by changing the resolution and the width of
> the
> > TIFF file to one that is accepted by the fax standard. In my case I
> changed
> > to a resolution of 96x96 and a width of 1728.
> >
> > Now I am able to send faxes, but something weird is happening, the fax
> > received in the fax-machine has the black and white colours inverted.
Any
> > ideas why this could be happening?
>
> The way I got my tiff file for testing was to use ReceiveFax to make a
> tiff from an inbound fax.
>
> I then used that tiff outbound for testing outbound faxing.
>
> Something you might want to consider doing?
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20090312/2037ec6c/attachment.htm