asterisk users - Jan 2011 - Unable to get Fax t38 working with IrisTel trunk

Hi everyone,
I have been trying to get T.38 Faxing to work with Iristel sip trunks for
last few days but havn't been sccussful.  I am using Asterisk 1.6.2.8 and
SpanDSP 0.6.  Here is what I see in the tcpdump capture:
1.  Call come in from the trunk as regular voice call with g.711 codec
2.  Asterisk answers the call and recognizes the CNG and sends the call to
fax extension
3.  Eventually Receive fax is called with a file name
4.  Asterisk sends update message to remote gateway with T38 codec
information
5. Remote server doesn't respond.  Asterisk resends update messages multiple
times.
6. Eventually remote gateway sends the invite with T38 codecs listed in the
SDP
7. Asterisk Responds back with 488 "Not acceptable here"
8. Another invite is send from the remote gateway with T38 codecs in the SDP
9. Asterisk sends OK but g.711 codecs listed in SDP.
10. remote gateway sends the BYE message and call is completed.

The questions I have are:
Why Asterisk sends update message in step 4 above instead of send an invite?
Why Asterisk responds back with 488 in step 7 above?
Why asterisk sends g.711 codecs in step 9 above?

Thanks

Karim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20110111/bf2789d5/attachment.htm>

On 01/11/2011 04:28 PM, Karim Mardhani wrote:
> Hi everyone,
> I have been trying to get T.38 Faxing to work with Iristel sip trunks
> for last few days but havn't been sccussful.  I am using Asterisk
> 1.6.2.8 and SpanDSP 0.6.  Here is what I see in the tcpdump capture:
You are 7 versions behind on Asterisk (the current version is 1.6.2.15, 
and 1.6.2.16 will be released today or tomorrow), and there were 
significant improvements in T.38 negotiation between those releases. 
Before spending too much more time on this, I would strongly suggest you 
update to the latest release in the 1.6.2 series.
> 1.  Call come in from the trunk as regular voice call with g.711 codec
> 2.  Asterisk answers the call and recognizes the CNG and sends the call
> to fax extension
> 3.  Eventually Receive fax is called with a file name
> 4.  Asterisk sends update message to remote gateway with T38 codec
> information
Do you mean a SIP 'UPDATE' request?
> 5. Remote server doesn't respond.  Asterisk resends update messages
> multiple times.
Then the IrisTel SIP implementation is broken. If it receives a SIP 
request it does not understand, or does not want to process, it *still* 
has to respond to indicate that to the sender of the request. Ignoring 
the request will result in broken behavior.
> 6. Eventually remote gateway sends the invite with T38 codecs listed in
> the SDP
I assume you mean a re-INVITE here.
> 7. Asterisk Responds back with 488 "Not acceptable here"
Was ReceiveFAX still running when this happened, or had it given up 
trying to switch the session to T.38 mode? Asterisk will respond with 
488 to a T.38 re-INVITE when it cannot switch the channel to T.38 mode 
because there isn't a T.38 endpoint available... and ReceiveFAX will 
only wait for a reasonable period of time for the sending endpoint to 
switch to T.38 before falling back to audio FAX mode.
> 8. Another invite is send from the remote gateway with T38 codecs in the
SDP
Was image/t38 the *only* media format offered?
> 9. Asterisk sends OK but g.711 codecs listed in SDP.
> 10. remote gateway sends the BYE message and call is completed.
>
> The questions I have are:
> Why Asterisk sends update message in step 4 above instead of send an
invite?
Do you have 'directmedia=update' or 'canreinvite=update' set in
sip.conf
for this endpoint? If so, Asterisk will send UPDATE instead of re-INVITE 
requests because you told it to :-)
> Why Asterisk responds back with 488 in step 7 above?
> Why asterisk sends g.711 codecs in step 9 above?
This will depend on the answers to the questions I included above.

When debugging problems like this, it is very important to have both a 
packet capture *and* a complete console log (with as much verbosity and 
debugging enabled as possible) so that all factors involved can be 
considered.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org