| Summary: | ASTERISK-08497: asterisk reinvites to G.711 after a T.38 negotiation - fax fails depending on ATA config | ||
| Reporter: | Alexander Tull (alex-911) | Labels: | |
| Date Opened: | 2007-01-05 12:29:06.000-0600 | Date Closed: | 2011-06-07 14:02:57 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/T.38 |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) test1-1.4.2-20070329-2.txt ( 1) test2-1.4.2-20070329-2.txt | |
| Description: | I have the following setup for outgoing fax calls to PSTN: G3FAX - LinksysATA SPA-2102 - Asterisk 1.4 - SessionBorderController - Cisco Class4 CA - Cisco AS series MG - PSTN depending on the SPA config, there are several possibilities how T.38 calls are handled. test 1 (test1.txt): next to T.38 enabled, there is FAX Passthru Method NSE enabled. that forces the call setup like this: SPA invites for PCMA. the Cisco MG detects fax and the Cisco CA reinvites for T.38. in this scenario, T.38 is negotiated and the fax is sent to the receiver. after the fax has been sent, asterisk sends a reinvite for G.711 to the SPA-2102..? the SPA sends BYE, the fax passed through. asterisk's reinvite didn't disturb in this case, but what was it good for? test 2 (test2.txt): when I disable the FAX passthru Method on the SPA-2102, the call setup is different: now it is the SPA itself who reinvites for T.38 after it detects FAX locally on the line. here, asterisks reinvites immediately for PCMA towards the call agent. the T.38 negotiation fails and no fax passes through. ****** ADDITIONAL INFORMATION ****** SPA-2102 sw version 3.3.6 Linux kernel is 2.4.21-243-smp4G on a Dell Poweredge distri is a Suse10 (forgive me that) from sip.conf: [general] t38pt_udptl = yes [123450111] ;-) SPA-2102 Line 1 type=friend context=privileged regexten=123450111 callerid=blabla <0123450111> secret=secret host=dynamic nat=yes canreinvite=yes disallow=all allow=alaw allow=gsm allw=ilbc t38pt_udptl = yes caller: 012345011 called: 0123456789 SPA NAT inside:192.168.0.12 SPA NAT outside: 10.10.10.23 asterisk 1.4: 172.16.0.25 Session Border B2BUA: 172.16.0.20 | ||
| Comments: | By: Olle Johansson (oej) 2007-01-08 05:53:55.000-0600 Please upload text files instead of archives in the future, thanks. By: Serge Vecher (serge-v) 2007-03-20 14:54:27 alex-911: what are the test results with 1.4.2? By: Alexander Tull (alex-911) 2007-03-29 09:28:56 with 1.4.2, test 1 is the same. test 2 is different: the re-INVITEs of asterisk (External RTP bridge) and the SPA (T.38) overlap which results in 491s from both sides. asterisk provides a hangup cause in the 491 already and releases afterwards with a BYE...? the spec says the UAS should "adjust the session", what's your opinion on that? the difference in the test setup now: the SPA is not behind NAT. By: Alexander Tull (alex-911) 2007-03-30 03:06:36 ok, the handling of the 491 is not according to the RFC. do you want a seperate bug ID for that? it's not related to fax or T.38 By: Serge Vecher (serge-v) 2007-03-30 08:51:32 alex-911: yes, please file the 491 issue separately with the appropriate debuglog attached. By: Joshua C. Colp (jcolp) 2007-12-18 10:18:55.000-0600 I can confirm during my latest tests that this is no longer an issue. | ||