We don't have an ATA and fax machine. The whole point (as I specified in the header and initial message) is the attempt to use "Fax for Asterisk" to send the message.
As I showed in the logs, the remote carrier sends a proper T.38 reINVITE, but our Asterisk doesn't accept, despite the fact that this provider is defined in sip.conf with both canreinvite and t38pt_udptl enabled, so the only question is (as far as we understand) is why in this scenario, the T.38 is rejected. Here are the logs (sip debug is open) again, since we get the reINVITE: <--- SIP read from UDP:xxx.xxx.xxx.xx8:5060 ---> INVITE sip:1234...@10.0.0.3:5060 SIP/2.0 Via: SIP/2.0/UDP xxx.xxx.xxx.xx8:5060;branch=z9hG4bK0dB004c7e5e3c3e60a8 From: <sip:98765...@xxx.xxx.xxx.xx8:5060><sip:98765...@xxx.xxx.xxx.xx8:5060>;tag=gK0d817deb To: "Fax" <sip:1234...@yyy.yyy.yyy.yyy> <sip:1234...@yyy.yyy.yyy.yyy>;tag=as0ddeacb5 Call-ID: 74ca1e4e3e86a1b873428773477e2...@yyy.yyy.yyy.yyy CSeq: 1785 INVITE Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,INFO,NOTIFY,PRACK,UPDATE,MESSAGE,PUBLISH Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: <sip:98765...@xxx.xxx.xxx.xx8:5060><sip:98765...@xxx.xxx.xxx.xx8:5060> Supported: timer Session-Expires: 1800;refresher=uas Min-SE: 90 Content-Length: 303 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 218 7126 IN IP4 xxx.xxx.xxx.xx8 s=SIP Media Capabilities c=IN IP4 xxx.xxx.xxx.xx7 t=0 0 m=image 6202 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:262 a=T38FaxMaxDatagram:176 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv <-------------> --- (16 headers 13 lines) --- Sending to xxx.xxx.xxx.xx8 : 5060 (no NAT) Got T.38 offer in SDP in dialog 74ca1e4e3e86a1b873428773477e2...@yyy.yyy.yyy.yyy Capabilities: us - 0x102 (gsm|g729), peer - audio=0x0 (nothing)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x0 (nothing) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing) Got T.38 Re-invite without audio. Keeping RTP active during T.38 session. <--- Transmitting (no NAT) to xxx.xxx.xxx.xx8:5060 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP xxx.xxx.xxx.xx8:5060;branch=z9hG4bK0dB004c7e5e3c3e60a8;received=xxx.xxx.xxx.xx8 From: <sip:98765...@xxx.xxx.xxx.xx8:5060><sip:98765...@xxx.xxx.xxx.xx8:5060>;tag=gK0d817deb To: "Fax" <sip:1234...@yyy.yyy.yyy.yyy> <sip:1234...@yyy.yyy.yyy.yyy>;tag=as0ddeacb5 Call-ID: 74ca1e4e3e86a1b873428773477e2...@yyy.yyy.yyy.yyy CSeq: 1785 INVITE Server: Smartel-PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer Contact: <sip:1234...@yyy.yyy.yyy.yyy> <sip:1234...@yyy.yyy.yyy.yyy> Content-Length: 0 <------------> <--- Reliably Transmitting (no NAT) to xxx.xxx.xxx.xx8:5060 ---> SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP xxx.xxx.xxx.xx8:5060;branch=z9hG4bK0dB004c7e5e3c3e60a8;received=xxx.xxx.xxx.xx8 From: <sip:98765...@xxx.xxx.xxx.xx8:5060><sip:98765...@xxx.xxx.xxx.xx8:5060>;tag=gK0d817deb To: "Fax" <sip:1234...@yyy.yyy.yyy.yyy> <sip:1234...@yyy.yyy.yyy.yyy>;tag=as0ddeacb5 Call-ID: 74ca1e4e3e86a1b873428773477e2...@yyy.yyy.yyy.yyy CSeq: 1785 INVITE Server: Smartel-PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces, timer Content-Length: 0 Thanks. Michael On Tue, Oct 19, 2010 at 5:40 PM, David Backeberg <dbackeb...@gmail.com>wrote: > On Tue, Oct 19, 2010 at 11:21 AM, VoIP Question <voip.quest...@gmail.com> > wrote: > > It's set to yes for this peer. > > > > also t38pt_udptl is set to yes. > > > > :( > > You don't say anything about what you're trying to send / receive against. > > Here's how you should troubleshoot: > > * start with a 'real fax machine' if you have one, on an analog line > if you have one. If you can't receive / send with that against your > target, blame your target. > * move to audio-pass through fax on asterisk. No T.38. If that works. > * add in T.38 > > You will learn things in that process and be able to tell at what > layer your troubles are happening. > > It could be coincidental that things give up during the reinvite. It > could actually be giving up for noise on the line, packet drops, etc. > > At the very least, start recording the call. You'll at least be able > to hear up to the re-invite. > > Definitely record the audio passthrough attempt and listen back to it. > > -- > _____________________________________________________________________ > -- 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 >
-- _____________________________________________________________________ -- 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
