Recursive
2014-Dec-11 08:52 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
Hello, at first, thanks for helping! In the meantime, I have done a lot of research and trial and error, and I could solve that specific problem. Obviously, the dialplan application "Answer" was playing a key role here. My original dialplan snippet (which produced that problem) was: exten => _00., 1, NoOp() same => n, Set(FAXOPT(gateway)=yes) same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg) same => n, Hangup() The problem vanished when I changed that to: exten => _00., 1, NoOp() same => n, Answer() same => n, Progress() same => n, Set(FAXOPT(gateway)=yes) same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg) same => n, Hangup() However, I got another problem then: The fax training now went well, and a part of the fax was transmitted, i.e. switching from G711 to T32 now worked. But after 32 seconds (measured from the begin of the transmission) Asterisk claimed that there was a timeout with receiving an answer to a critical packet, and ended the transmission (by sending BYE messages to both ends). Wireshark and SIP debug analysis have shown that this error message is completely humbug. I have thoroughly gone through the logs line by line more times that I could count, and (by following the CSeq) I every time have seen that the error message was relating to one or more OK messages which Asterisk had sent to the provider, but I swear that the provider correctly had ACKed every single of these OK messages. So I really can't imagine how Asterisk came to the idea that it hadn't received the answer. Maybe my interpretation of the logs is wrong, but if Wireshark's logs show an ACK for every OK, all should be well, shouldn't it? Anyway, that means that I now can send an average one page fax document to fast endpoints which do the training quickly and provide high data rates. But if the endpoint is slower or if the fax document has multiple pages or a disadvantageous structure, it will take more than 32 seconds to transmit and thus will be cut by Asterisk. The receiving fax machine in this case either sees a part of the page or some weird random patterns. I think that this is a bug in chan_sip which seemingly does not have the best reputation when it comes to T38. The erroneous behaviour has shown in every test I have done (4 different fax machines at the other end serviced by three different providers, each tested with two different SIP providers (trunks)). At this point, I have given up chan_sip and hoped that pjsip would behave correctly, but what a frustration: Although spending three complete days with it, I even couldn't make it do the training. It always makes the SIP provider switch to T38 at once at the very beginning of the transmission which of course won't work. I think I'll open another thread about that problem; it's somehow off-topic here. Regards and thank you very much, Recursive On 10.12.2014 11:42, Frederic Van Espen wrote:> Hi, > > On Tue, Dec 2, 2014 at 9:24 AM, Recursive <lists at binarus.de> wrote: >> - Packets 14313, 14314: The provider re-invites asterisk for T.38 (confirmed by viewing the packet's details), asterisk answers "Trying ..." to the provider >> - Packets 14315, 14321, 14322: Asterisk re-invites the local endpoint (again confirmed by looking into the packet's details), the local endpoint answers "OK", and asterisk ACKs the OK. >> - Packets 14323, 14329: Asterisk accepts the invitation from the provider by sending "OK" to the provider, and the provider ACKs the OK. >> - Packets 14453, 14454 and 14649: The local endpoint again tries to re-invite asterisk for T.38 (confirmed by looking into the packet's details), Asterisk answers "Trying" and then refuses, saying "488: Not acceptable here" >> - From then on, things go horribly wrong (probably, the local endpoint is still expecting G.711 packets, but gets T.38 packets) >> >> I have provided all packets which are relevant. The packet numbers are not contiguous since asterisk currently is on a test server which runs many other services (the packets of which I have filtered out). >> >> I didn't want to clutter this post too much, thus I have only provided an overview and not the details of each packet. Furthermore, please forgive me that it's much easier for me to read Wireshark's logs than Asterisk's logs. Of course, I will provide every log anybody trying to help out asks me for. >> >> But my first question is a very simple one: >> >> From the log above, I am quite sure that switching to T.38 is done right up to (and including) packet 14329. I think that my local endpoint then misbehaves by again re-inviting asterisk for T.38 (as all parties already have agreed upon T.38). >> >> Thus, is my endpoint really misbehaving, and if yes, is there anything I can do about it on Asterisk's side? Or do the SIP/T.38 state machines allow such (seemingly superfluous) re-invite, and it's Asterisk's fault to answer with 488? > > - Could you share the details of the SDP in each INVITE and OK packet? > - How are your SIP endpoints configured in asterisk sip.conf? (the SIP > trunk provider and the local endpoint) > - What type is the local endpoint? > > Cheers, > > Frederic >
Larry Moore
2014-Dec-11 10:53 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
On 11/12/2014 4:52 PM, Recursive wrote:> Hello, > > at first, thanks for helping! > > In the meantime, I have done a lot of research and trial and error, and I could solve that specific problem. Obviously, the dialplan application "Answer" was playing a key role here. My original dialplan snippet (which produced that problem) was: >You may very well find getting T.38 working in your environment in a way you would like will consume a large amount of your time, you will also find yourself doing a lot of research. What you should have found out by now (or perhaps deduced) is that the T.38 is a standard that is varied thus one cannot be assured a T.38 solution will always work.> exten => _00., 1, NoOp() > same => n, Set(FAXOPT(gateway)=yes) > same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg) > same => n, Hangup() > > The problem vanished when I changed that to: > > exten => _00., 1, NoOp() > same => n, Answer() > same => n, Progress() > same => n, Set(FAXOPT(gateway)=yes) > same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg) > same => n, Hangup() >One may assume this is your dialplan for the outgoing connection with which you want T.38 to be supported. To obtain better assistance you will need to include information such as what the local T.38 endpoint is and how it connects to your system. If it is in fact a T.38 capable endpoint then you should setting FAXOPT(gateway) to no. having Answer() & Progress() for an outgoing T.38 connection doesn't seem to make sense to me! You should also include information relating to your SIP configuration (with appropriate obfuscations) for the connection to peer 27XgY8YwfI2S9NAg as well as what T.38 options you have set in the general section of sip.conf. Larry.
Recursive
2014-Dec-15 07:51 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
On 11.12.2014 11:53, Larry Moore wrote:> You may very well find getting T.38 working in your environment in a way you would like will consume a large amount of your time, you will also find yourself doing a lot of research. What you should have found out by now (or perhaps deduced) is that the T.38 is a standard that is varied thus one cannot be assured a T.38 solution will always work.Agreed. But firstly, I really need a working fax, and secondly, I am just trying to make it work with one specific provider (I have identified two providers in Germany which could be a possibility and have signed up a full account with both of them for testing purposes (no problem since the fees are small and the cancellation period is short in both cases), and as soon as one of these works like expected I'll cancel the contract with the other one). So I don't need to have a general solution which works with every provider around the world.>> exten => _00., 1, NoOp() >> same => n, Answer() >> same => n, Progress() >> same => n, Set(FAXOPT(gateway)=yes) >> same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg) >> same => n, Hangup() > > One may assume this is your dialplan for the outgoing connection with which you want T.38 to be supported.You are right.> To obtain better assistance you will need to include information such as what the local T.38 endpoint is and how it connects to your system. If it is in fact a T.38 capable endpoint then you should setting FAXOPT(gateway) to no. having Answer() & Progress() for an outgoing T.38 connection doesn't seem to make sense to me!The endpoint is T.38 capable. I have configured FAXOPT(gateway)=yes because I have read that the gateway automatically goes out of the way if Asterisk determines that the two endpoints which should be connected use the same protocols and parameters, and otherwise translates between the endpoints (see https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway, section "Using T.38 gateway mode"). Furthermore, T.38 passthrough never worked for me. My initial tries were with Asterisk 1.8 which is included in Debian wheezy (and does not have the gateway capability anyway), but whatever I did there, no T.38 INVITE was accepted by Asterisk (this was some weeks ago, so I don't remember the details). I then downloaded, compiled and installed Asterisk 13.0.1 and tried T.38 passthrough, but to no avail as well. When I added FAXOPT(gateway)=yes, I saw correct T.38 INVITEs for the first time. Regarding Progress(), I am not sure if I need this. I think one day I could solve a certain problem by using it, but I really have done a million of tries and don't remember every one. Regarding Answer(), I think I need this. Without Answer(), no T.38 would be used in many cases; it seems that switching from initial G.711 to T.38 is done in-band, and that couldn't be done without the Answer() in the dialplan, could it?> You should also include information relating to your SIP configuration (with appropriate obfuscations) for the connection to peer 27XgY8YwfI2S9NAg as well as what T.38 options you have set in the general section of sip.conf.You are right. I will now provide every detail and the logs. By the way, I have switched back to chan_sip today for the purpose of testing again and generating logs. Unfortunately, the moderator rejected this message in the first version due to oversize (40 kB limit), so I now have removed the logs and instead have put them onto a web server for download. The Wireshark overview log (all packets of the fax transmission) is here: http://www.omeganet.de/t38-overview-log.txt The detailed packet contents of all INVITE, OK and ACK packets are here: http://www.omeganet.de/t38-detailed-log.txt General remarks: - Asterisk runs on the IP address 192.168.20.48. - The hostname spock-asterisk.home.omeganet.de resolves to that IP address. - The fax software is Tobit David which is T.38 capable. I can't use another fax software; an extensive explanation for that would be off-topic here, but if somebody is interested, I will send respective information via PM. - The fax software runs on another machine than Asterisk. - The fax software runs on the IP address 192.168.20.14. - I don't want Asterisk to do any NAT wizardry because I have configured my firewall to do the NAT for SIP and RTP. - I am very sure that NAT is not the problem. - In extensions.conf, I basically have configured only one extension pattern for outbound fax calls (to keep tests simple). The pattern is _00. (for testing, I make the fax software call numbers which always begin with 0049, so this pattern is sufficient). - In sip.conf, the context for the provider is "unauthenticated" since the first step is to send a fax (and not to receive one, which I think is more complicated). Wireshark overview log remarks: - The overview log shows that it works in principle: A first INVITE series happens, and some G.711 data is exchanged between Asterisk and the fax software. - After this, a second INVITE series happens, everybody switches to T.38, and UDPTL packets are exchanged. - The second INVITE series starts at second 15 (packet 28879). - The second INVITE series is begun by the local fax software with CSeq 4264. - Up to this point, all INVITEs, OKs and ACKs are in the right order. - The training begins and is finished successfully, and the actual fax data begins to flow. - Every few seconds, Asterisk send an OK message (with CSeq 4264 (as in original INVITE)) to the local fax software. - Please note that the local fax software *always* correctly ACKs these OK messages (with CSeq 4264 (as in original INVITE)). - Nevertheless, at about second 47, Asterisk says "BYE" to both parties (i.e. local fax software and provider) *although* the fax transfer is not finished yet. - Note that there are 32 seconds between the begin of the second INVITE series and the BYE messages. Asterisk console log remarks: - I do the tests after having started Asterisk by "asterisk -c" so that I immediately see serious errors or warnings at the console. - In this case, after having freshly started Asterisk, having re-registered the fax software endpoint, and having tried to send the fax, there are two console messages. The first one claims that the critical packet with CSeq 4264 timed out after 32 seconds, and the second one tells us that Asterisk hung up due to this. - Please note that the 32 seconds are exactly the time between the second INVITE series and the BYE messages in the Wireshark overview log. - This means that Asterisk thinks that packet CSeq 4264 has timed out *although* the Wireshark overview log clearly shows that every packet of this CSeq has been ACKed by the local fax software. Oddities which I have seen myself so far (which may or may not be responsible for the failures - this is beyond my current knowledge): - At the begin of the T.38 communication (packet 28879), the local fax software invites Asterisk with 0049... at ..., and Asterisk then invites the provider with 49... at ..., i.e. Asterisk cuts off the leading two zeroes. Why? I don't think my dialplan does Asterisk instruct to do so. - In packet 28887, Asterisk gives 0049... at 192.168.20.48 as contact. But in the original invite in packet 28879, the contact was 0049... at spock-asterisk.home.omeganet.de. Is this bad? Thank you very much in advance to everybody who tries to help. Regards, Recursive ******************** This is my sip.conf: ******************** [general] session-timers = refuse context=unauthenticated allowguest=no allowoverlap=no udpbindaddr=192.168.20.48:5060 tcpenable=no tcpbindaddr=192.168.20.48:5060 tlsenable=no tlsbindaddr=192.168.20.48:5061 transport=udp srvlookup=no defaultexpiry=600 nat = no directmedia = no ignoresdpversion=yes register => USERNAME_PROVIDER:PASSWORD_PROVIDER at proxy.provider.net/USERNAME_PROVIDER [authentication] ;David T38 endpoint [bCo9m7OfHWK2Y2sb] context = david_t38_inbound type = peer host = dynamic secret = PASSWORD_FAX t38pt_udptl = yes,redundancy,maxdatagram=400 t38pt_rtp = no t38pt_tcp = no insecure = port,invite canreinvite = yes ;Trunk (SIP provider) [USERNAME_PROVIDER] context = unauthenticated type = peer host = proxy.provider.net outboundproxy = proxy.provider.net defaultuser = USERNAME_PROVIDER fromuser = USERNAME_PROVIDER fromdomain = proxy.provider.net remotesecret = PASSWORD_PROVIDER insecure = port,invite t38pt_udptl = yes,redundancy,maxdatagram=400 t38_rtp = no t38_tcp = no canreinvite = yes *************************** This is my extensions.conf: *************************** [general] static=yes writeprotect=no clearglobalvars=no [globals] [default] exten => s, 1, Hangup() [unauthenticated] exten => s, 1, Hangup() [david_t38_inbound] exten => _00., 1, NoOp() same => n, Answer() same => n, Progress() same => n, Set(FAXOPT(gateway)=yes) same => n, Dial(SIP/${EXTEN}@USERNAME_PROVIDER) same => n, Hangup() ********************************************* These are the messages in Asterisk's console: ********************************************* *CLI> [Dec 13 12:51:01] WARNING[5651]: chan_sip.c:4046 retrans_pkt: Retransmission timeout reached on transmission 24edd33abaae904f for seqno 4264 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 32000ms with no response [Dec 13 12:51:01] WARNING[5651]: chan_sip.c:4075 retrans_pkt: Hanging up call 24edd33abaae904f - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
Recursive
2014-Dec-15 09:34 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
On 14.12.2014 22:10, Larry Moore wrote:> Asterisk 1.8 with the T.38 Gateway patch (not the one by Niccol? Belli) sends a T.38 invite to the ITSP when the fax tones are detected from the callee, the T.38 Gateway implementation in Asterisk 10 and Niccol?'s back-port for Asterisk 1.8.11 does not behave this way. >Just to be sure: Is this the situation with FAXOPT(gateway)=no or with FAXOPT(gateway)=yes?> The real issue here is having current versions of Asterisk & T.38 working as expected all the way through. >Only my initial tries were with Asterisk 1.8. Since that didn't work in any way, I have downloaded and compiled Asterisk 13.0.1, and I am currently using no other major version than 13 when doing the tests.> Perhaps you have a good reason for wanting to set up your firewall to handle SIP and RTP, presumably using a SIP ALG - for the sake of testing and confirming your problem is not related to your firewall's NAT wizardry I would advise you disable this on the firewall and enable NAT in Asterisk, this should only be required for the trunk or any other connection traversing your firewall to the Internet from Asterisk. Of course you will need to allow ports through for RTP and UDPTL, you can list the range of UDPTL ports using the command 'udptl show config'. >The first reason is that I am quite familiar with firewalls, but not with Asterisk :-) The second reason is that (as far as I have understood) you eventually have to enable port forwarding for the RTP packets in the firewall if you let Asterisk do the NAT. That's a thing I don't want to do for several reasons. Instead, I prefer to let the firewall inspect the SIP packets and to open the associated ports for the associated streams dynamically. This works like a charm so far, for my fax tests as well as for my SIP phones (I don't have any problems with voice VoIP calls, inbound or outbound). I know that I eventually will get problems when it comes to encrypted calls, but that's a project for a later time. However, I'll do what you suggested for testing purposes. But I'm wondering how that could change the situation. From my understanding, my problem is that asterisk hangs up the call because it believes that it didn't get a timely reply to a packet which it has sent to the _local_ fax software. There is _no_ firewall between Asterisk and the local fax software; they are in the same network (192.168.20.x).> In Wireshark, have you used the 'VoIP Calls' option under Telephony then selected a sessions and clicked on the 'Flow' button, it may be helpful? >No, I just have captured all traffic on the machine where Asterisk runs (using tcpdump), have imported the dump into Wireshark and have filtered out all packets which are not IP packets to or from Asterisk (192.168.20.48). I am convinced that I am seeing the complete conversation after that.> I suspect because you have set Session Timers to be rejected, one of the endpoints is relying upon this being enabled. There doesn't appear to be anything in the Asterisk logs relating to Session Timers! >I set session-timers = refuse because the ITSP instructed me to do so. I will change that and test.> What is the 'Refresh' value returned from 'sip show registry'? >*CLI> sip show registry Host dnsmgr Username Refresh State Reg.Time proxy.provider.net:5060 N USERNAME_PROVIDER 585 Registered Mon, 15 Dec 2014 09:33:44 1 SIP registrations.> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', I don't know what Asterisk 13 will do with this setting. >I suspect Asterisk 13 will just ignore it. To make things worse, there seems to be a configuration directive named reinvite (not a typo); I have found it in at least one example and one article, but with no documentation, so the difference between canreinvite and reinvite is completely unclear to me. chan_sip seems to be documented very poorly, unlike chan_pjsip / res_pjsip.> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', it may be safer to add 'directmedia=no' to your peer configurations in case you change the global setting. >I'll add directmedia = no to the peer configuration, and I'll remove canreinvite at all since I definitely won't use Asterisk below major version 13 any more.> With your firewall having the SIP and RTP wizadry disabled and Asterisk set up to use Session-Timers and NAT your connection (you may need to set up port forwardings for RTCP to work) it would be interesting to know if the following dialplan will allow T.38 to be established. > > [david_t38_inbound] > exten => _00., 1, NoOp() > same => n, Set(FAXOPT(gateway)=no) > same => n, Dial(SIP/${EXTEN}@USERNAME_PROVIDER) > same => n, Hangup() > > > If no T.38 negotiation occurs I suspect your ITSP is not sending the T.38 re-invite for your outgoing call. >I'll try and report back. Larry, thanks for your valuable time and hints. I will need some days to try all the things you suggested, to record the logs and to report the results. But while doing so, I think we shouldn't forget that I'm almost there. At least, I obviously can transfer fax data via T.38, and I am convinced that it would work completely if Asterisk didn't hangup the call (seemingly) without any reason. Although I would be happy if I could make T.38 work as intended by its designers, I would be happy as well if I only could make it work in practice, independent of the theory. Thus, hoping to not being flamed after having said this, since I'm almost there, it is not important for me who invites whom, but I think the key to success would be to find out why Asterisk hangs up the call prematurely. Of course, I will try all your suggestions. But I am also still seeing a chance to solve the problem by looking into the logs. There must be something which explains the premature hangup, something which I have not seen yet due to my limited knowledge. Do you have any additional idea regarding this? Do you see any packet in the logs from Asterisk to the local fax software which is not answered timely and appropriately? Thank you very much, Recursive
Matthew Jordan
2014-Dec-15 13:58 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
On Mon, Dec 15, 2014 at 3:34 AM, Recursive <lists at binarus.de> wrote:><snip>>> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', I don't know what Asterisk 13 will do with this setting. >> > I suspect Asterisk 13 will just ignore it. To make things worse, there seems to be a configuration directive named reinvite (not a typo); I have found it in at least one example and one article, but with no documentation, so the difference between canreinvite and reinvite is completely unclear to me. chan_sip seems to be documented very poorly, unlike chan_pjsip / res_pjsip.I'm just going to comment on the 'directmedia'/'canreinvite' points here. 1) There is no 'reinvite' setting in chan_sip. If you patched Asterisk, than your mileage may vary. 2) 'directmedia' is the same thing as 'canreinvite'. They are the same setting. 'directmedia' replaced the nomenclature 'canreinvite' because it actually describes what the setting does: it determines whether or not Asterisk will attempt to re-INVITE media directly between RTP capable peers. 3) While documentation sometimes is lacking for some parts of Asterisk, this setting is actually pretty well documented in sip.conf.sample: {quote} ; By default, Asterisk tries to re-invite media streams to an optimal path. If there's ; no reason for Asterisk to stay in the media path, the media will be redirected. ; This does not really work well in the case where Asterisk is outside and the ; clients are on the inside of a NAT. In that case, you want to set directmedia=nonat. ; ;directmedia=yes ; Asterisk by default tries to redirect the ; RTP media stream to go directly from ; the caller to the callee. Some devices do not ; support this (especially if one of them is behind a NAT). ; The default setting is YES. If you have all clients ; behind a NAT, or for some other reason want Asterisk to ; stay in the audio path, you may want to turn this off. ; This setting also affect direct RTP ; at call setup (a new feature in 1.4 - setting up the ; call directly between the endpoints instead of sending ; a re-INVITE). ; Additionally this option does not disable all reINVITE operations. ; It only controls Asterisk generating reINVITEs for the specific ; purpose of setting up a direct media path. If a reINVITE is ; needed to switch a media stream to inactive (when placed on ; hold) or to T.38, it will still be done, regardless of this ; setting. Note that direct T.38 is not supported. ;directmedia=nonat ; An additional option is to allow media path redirection ; (reinvite) but only when the peer where the media is being ; sent is known to not be behind a NAT (as the RTP core can ; determine it based on the apparent IP address the media ; arrives from). ;directmedia=update ; Yet a third option... use UPDATE for media path redirection, ; instead of INVITE. This can be combined with 'nonat', as ; 'directmedia=update,nonat'. It implies 'yes'. ;directmedia=outgoing ; When sending directmedia reinvites, do not send an immediate ; reinvite on an incoming call leg. This option is useful when ; peered with another SIP user agent that is known to send ; immediate direct media reinvites upon call establishment. Setting ; the option in this situation helps to prevent potential glares. ; Setting this option implies 'yes'. {quote} Note that none of this matters until you are in a bridge. If you are in a bridge, I would expect Asterisk to re-INVITE the media back to Asterisk when one of the sides offers T.38 (and, in fact, we have automated tests that check for this sort of thing). You shouldn't have to set directmedia to 'no', but - in the interest of making your system easier to debug and to remove variables - you may want to set it to 'no' for the involved peers.>> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', it may be safer to add 'directmedia=no' to your peer configurations in case you change the global setting. >> > I'll add directmedia = no to the peer configuration, and I'll remove canreinvite at all since I definitely won't use Asterisk below major version 13 any more.Just use 'directmedia'. They are the same setting (snippet from chan_sip's configuration parsing): } else if (!strcasecmp(v->name, "directmedia") || !strcasecmp(v->name, "canreinvite")) { ast_set_flag(&mask[0], SIP_REINVITE); ... Note that these settings and their behaviour is the same from 1.8 through 13. While I'm glad to see anyone using the latest and greatest - yay Asterisk 13! - this isn't a reason to go to Asterisk 13. Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
Larry Moore
2014-Dec-16 10:41 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
Just a thought regarding testing. Create a suitable TIFF file with more than 30 seconds worth of data and send it from Asterisk using SendFAX() to convince yourself whether Asterisk will work with your ITSP, you may still need to enable session timers. Have you considered setting up an extension on your Asterisk server which will receive the fax e.g. using ReceiveFAX() and see if your connection problem persists? Larry. On 15/12/2014 5:10 AM, Larry Moore wrote:> > > On 14/12/2014 7:24 PM, Recursive wrote: >> >> On 11.12.2014 11:53, Larry Moore wrote: >>> You may very well find getting T.38 working in your environment in a >>> way you would like will consume a large amount of your time, you will >>> also find yourself doing a lot of research. What you should have >>> found out by now (or perhaps deduced) is that the T.38 is a standard >>> that is varied thus one cannot be assured a T.38 solution will always >>> work. >> >> Agreed. But firstly, I really need a working fax, and secondly, I am >> just trying to make it work with one specific provider (I have >> identified two providers in Germany which could be a possibility and >> have signed up a full account with both of them for testing purposes >> (no problem since the fees are small and the cancellation period is >> short in both cases), and as soon as one of these works like expected >> I'll cancel the contract with the other one). So I don't need to have >> a general solution which works with every provider around the world. >> >>>> exten => _00., 1, NoOp() >>>> same => n, Answer() >>>> same => n, Progress() >>>> same => n, Set(FAXOPT(gateway)=yes) >>>> same => n, Dial(SIP/${EXTEN}@27XgY8YwfI2S9NAg) >>>> same => n, Hangup() >>> >>> One may assume this is your dialplan for the outgoing connection with >>> which you want T.38 to be supported. >> >> You are right. >> >>> To obtain better assistance you will need to include information such >>> as what the local T.38 endpoint is and how it connects to your >>> system. If it is in fact a T.38 capable endpoint then you should >>> setting FAXOPT(gateway) to no. having Answer()& Progress() for an >>> outgoing T.38 connection doesn't seem to make sense to me! >> >> The endpoint is T.38 capable. I have configured FAXOPT(gateway)=yes >> because I have read that the gateway automatically goes out of the way >> if Asterisk determines that the two endpoints which should be >> connected use the same protocols and parameters, and otherwise >> translates between the endpoints (see >> https://wiki.asterisk.org/wiki/display/AST/T.38+Fax+Gateway, section >> "Using T.38 gateway mode"). >> >> Furthermore, T.38 passthrough never worked for me. My initial tries >> were with Asterisk 1.8 which is included in Debian wheezy (and does >> not have the gateway capability anyway), but whatever I did there, no >> T.38 INVITE was accepted by Asterisk (this was some weeks ago, so I >> don't remember the details). I then downloaded, compiled and installed >> Asterisk 13.0.1 and tried T.38 passthrough, but to no avail as well. >> When I added FAXOPT(gateway)=yes, I saw correct T.38 INVITEs for the >> first time. >> > > See comment regarding 'canreinvite'. > >> Regarding Progress(), I am not sure if I need this. I think one day I >> could solve a certain problem by using it, but I really have done a >> million of tries and don't remember every one. >> >> Regarding Answer(), I think I need this. Without Answer(), no T.38 >> would be used in many cases; it seems that switching from initial >> G.711 to T.38 is done in-band, and that couldn't be done without the >> Answer() in the dialplan, could it? >> > > Your ITSP should be sending the T.38 invite to Asterisk when they detect > the fax tones from the answered call (callee), it would appear you are > _forcing_ the T.38 session by using the Answer() function, you are then > relying on the activity detection period of the FAXOPT(gateway) function > for the call to be established. > > Asterisk 1.8 with the T.38 Gateway patch (not the one by Niccol? Belli) > sends a T.38 invite to the ITSP when the fax tones are detected from the > callee, the T.38 Gateway implementation in Asterisk 10 and Niccol?'s > back-port for Asterisk 1.8.11 does not behave this way. > > The real issue here is having current versions of Asterisk & T.38 > working as expected all the way through. > >>> You should also include information relating to your SIP >>> configuration (with appropriate obfuscations) for the connection to >>> peer 27XgY8YwfI2S9NAg as well as what T.38 options you have set in >>> the general section of sip.conf. >> >> You are right. I will now provide every detail and the logs. By the >> way, I have switched back to chan_sip today for the purpose of testing >> again and generating logs. >> >> General remarks: >> >> - Asterisk runs on the IP address 192.168.20.48. >> - The hostname spock-asterisk.home.omeganet.de resolves to that IP >> address. >> - The fax software is Tobit David which is T.38 capable. I can't use >> another fax software; an extensive explanation for that would be >> off-topic here, but if somebody is interested, I will send respective >> information via PM. >> - The fax software runs on another machine than Asterisk. >> - The fax software runs on the IP address 192.168.20.14. >> - I don't want Asterisk to do any NAT wizardry because I have >> configured my firewall to do the NAT for SIP and RTP. >> - I am very sure that NAT is not the problem. > > Perhaps you have a good reason for wanting to set up your firewall to > handle SIP and RTP, presumably using a SIP ALG - for the sake of testing > and confirming your problem is not related to your firewall's NAT > wizardry I would advise you disable this on the firewall and enable NAT > in Asterisk, this should only be required for the trunk or any other > connection traversing your firewall to the Internet from Asterisk. Of > course you will need to allow ports through for RTP and UDPTL, you can > list the range of UDPTL ports using the command 'udptl show config'. > >> - In extensions.conf, I basically have configured only one extension >> pattern for outbound fax calls (to keep tests simple). The pattern is >> _00. (for testing, I make the fax software call numbers which always >> begin with 0049, so this pattern is sufficient). >> - In sip.conf, the context for the provider is "unauthenticated" since >> the first step is to send a fax (and not to receive one, which I think >> is more complicated). >> >> Wireshark overview log remarks: >> >> - The overview log shows that it works in principle: A first INVITE >> series happens, and some G.711 data is exchanged between Asterisk and >> the fax software. >> - After this, a second INVITE series happens, everybody switches to >> T.38, and UDPTL packets are exchanged. >> - The second INVITE series starts at second 15 (packet 28879). >> - The second INVITE series is begun by the local fax software with >> CSeq 4264. >> - Up to this point, all INVITEs, OKs and ACKs are in the right order. >> - The training begins and is finished successfully, and the actual fax >> data begins to flow. >> - Every few seconds, Asterisk send an OK message (with CSeq 4264 (as >> in original INVITE)) to the local fax software. >> - Please note that the local fax software *always* correctly ACKs >> these OK messages (with CSeq 4264 (as in original INVITE)). >> - Nevertheless, at about second 47, Asterisk says "BYE" to both >> parties (i.e. local fax software and provider) *although* the fax >> transfer is not finished yet. >> - Note that there are 32 seconds between the begin of the second >> INVITE series and the BYE messages. >> >> > > In Wireshark, have you used the 'VoIP Calls' option under Telephony then > selected a sessions and clicked on the 'Flow' button, it may be helpful? > > I suspect because you have set Session Timers to be rejected, one of the > endpoints is relying upon this being enabled. There doesn't appear to be > anything in the Asterisk logs relating to Session Timers! > > >> >> ******************** >> This is my sip.conf: >> ******************** >> >> [general] >> session-timers = refuse > > Try 'session-timers=accept' > >> context=unauthenticated >> allowguest=no >> allowoverlap=no >> udpbindaddr=192.168.20.48:5060 >> tcpenable=no >> tcpbindaddr=192.168.20.48:5060 >> tlsenable=no >> tlsbindaddr=192.168.20.48:5061 >> transport=udp >> srvlookup=no >> defaultexpiry=600 >> >> nat = no >> directmedia = no >> ignoresdpversion=yes >> >> register => >> USERNAME_PROVIDER:PASSWORD_PROVIDER at proxy.provider.net/USERNAME_PROVIDER >> > > What is the 'Refresh' value returned from 'sip show registry'? > >> [authentication] >> >> ;David T38 endpoint >> [bCo9m7OfHWK2Y2sb] >> context = david_t38_inbound >> type = peer >> host = dynamic >> secret = PASSWORD_FAX >> t38pt_udptl = yes,redundancy,maxdatagram=400 >> t38pt_rtp = no >> t38pt_tcp = no >> insecure = port,invite >> canreinvite = yes >> > > For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', I don't > know what Asterisk 13 will do with this setting. > >> ;Trunk (SIP provider) >> [USERNAME_PROVIDER] >> context = unauthenticated >> type = peer >> host = proxy.provider.net >> outboundproxy = proxy.provider.net >> defaultuser = USERNAME_PROVIDER >> fromuser = USERNAME_PROVIDER >> fromdomain = proxy.provider.net >> remotesecret = PASSWORD_PROVIDER >> insecure = port,invite >> t38pt_udptl = yes,redundancy,maxdatagram=400 >> t38_rtp = no >> t38_tcp = no >> canreinvite = yes >> > > For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', it may be > safer to add 'directmedia=no' to your peer configurations in case you > change the global setting. > >> >> *************************** >> This is my extensions.conf: >> *************************** >> >> [general] >> static=yes >> writeprotect=no >> clearglobalvars=no >> >> [globals] >> >> [default] >> exten => s, 1, Hangup() >> >> [unauthenticated] >> exten => s, 1, Hangup() >> >> [david_t38_inbound] >> exten => _00., 1, NoOp() >> same => n, Answer() >> same => n, Progress() >> same => n, Set(FAXOPT(gateway)=yes) >> same => n, Dial(SIP/${EXTEN}@USERNAME_PROVIDER) >> same => n, Hangup() >> >> > > With your firewall having the SIP and RTP wizadry disabled and Asterisk > set up to use Session-Timers and NAT your connection (you may need to > set up port forwardings for RTCP to work) it would be interesting to > know if the following dialplan will allow T.38 to be established. > > > [david_t38_inbound] > exten => _00., 1, NoOp() > same => n, Set(FAXOPT(gateway)=no) > same => n, Dial(SIP/${EXTEN}@USERNAME_PROVIDER) > same => n, Hangup() > > > If no T.38 negotiation occurs I suspect your ITSP is not sending the > T.38 re-invite for your outgoing call. > > Cheers, > > Larry.
Recursive
2014-Dec-17 08:08 UTC
[asterisk-users] T.38 not working - help needed with log interpretation
On 16.12.2014 11:41, Larry Moore wrote:> Just a thought regarding testing. > > Create a suitable TIFF file with more than 30 seconds worth of data and send it from Asterisk using SendFAX() to convince yourself whether Asterisk will work with your ITSP, you may still need to enable session timers. > > Have you considered setting up an extension on your Asterisk server which will receive the fax e.g. using ReceiveFAX() and see if your connection problem persists?Until now, I only have tested the sending direction (from the fax software's point of view) since the ITSP told me that would be the easy part. Some days ago, I made a dialplan with ReceiveFax() and was able to send a fax with multiple pages from the fax software to Asterisk. The TIFF file which Asterisk produced did not contain any errors, and there were no errors in the Asterisk logs or in the fax software's GUI. As a next step, I took that TIFF, made another dialplan with SendFax() and used that to send the TIFF file to another fax machine which is serviced by another ITSP (ISDN + PBX). Once again, this happened without any errors (same ITSP, same settings). So the problems seem to arise only when Asterisk is in the middle. I did not test the receive direction yet. I'll now backup my Asterisk configuration for future reference and research and start to try all the suggestions from the helpful people here step by step. I'll report back as soon I have a result. Regards, Recursive