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: kflem...@digium.com
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
