sean Posted December 4, 2009 Report Share Posted December 4, 2009 I need some help in sending fax through pbxnsip. (We'll deal with receiving a fax later Our setup: Internetprovider with SIP-GateWay (QSC), supports t38 pbxnsip v 3.3.1.3177 ATA (SPA2102), supports t38 Faxmaschine Our problem: We have enabled the speaker on the fax to listen in. When we register the ATA directly at the SIP-gateway of our provider, everything is perfect. When we register the ATA in pbxnsip (with identical settings), the following problem occurs: Fax is dialing, remoteparty is ringing, remoteparty picks up, our fax is sending CNG, and that's it! No CED from remote party is recieved. After a timeout the connection is terminated. The pbxnsip log and the statusinfo on the ATA show, that first the G711 codec is used and then it switches over to t38. It seems the remote fax is not recieving our CNG and therefor is not sending the CED. Find attached an example logfile and a screenshot of the configuration of our ATA. Any help would be greatly appreciated Cheers, sean pbixto_fax_log2.txt Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 14, 2009 Report Share Posted December 14, 2009 I guess the problem is the UPDATE message. The PBX assumes that the UA supports that method (it does advertize it), but obviously it does not work. There is a setting called "support_update" in the PBX; try setting it to "false" (see https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=413 on how to perform this setting change through the web interface without restarting the service). In later versions than the one you are using, we made the setting default to false. Seems UPDATE is not very well understood in the real SIP world. Quote Link to comment Share on other sites More sharing options...
sean Posted December 18, 2009 Author Report Share Posted December 18, 2009 I appreciate your help, but unfortunatly this did not solve the problem I changed the parameter "support_update" to false, and verfied it's value in pbx.xml This did not change anything, so I upgraded to pbxnsip v. 3.4.0.3201 by swapping the executable and restarting the service. Still same behaviour. My knowledge is not sufficient to analyze the corresponding network/SIP-traffic, but maybe you can find some hints. Find attached two traffic-capture files (Microsoft Network-Monitor), I hope they are compatible to display with other sniffers as well. They are both recorded on our NAT-router/Firewall. IP 192.168.0.209 is the ATA of the fax IP 192.168.0.210 is the pbxnsip IP 213.148.136.2 is the SIP-Gateway of our provider QSC The file ixto_fax_out_qsc.cap is capture of a successfull fax with the ATA registered directly at the SIP-Gateway of our Provider QSC. A capture-filter was applied for IP 192.168.0.209. The file ixto_fax_out_pbxnsip.cap is a capture of a failed attempt to send a fax through pbxnsip. A capture-filter was applied for IP 192.168.0.210. Any help would be greatly appreciated! Cheers, s. ixto_fax_out_capture.zip Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted December 21, 2009 Report Share Posted December 21, 2009 On the out capture, there is no traffic (at least I did not find anything) that shows the PBX being involved... Maybe that is the problem? Did you set an outbound proxy on the ATA that points to the PBX? Maybe the ATA tries to go directly to the service provider. The other thing that I can think of would be that there is a operating system service performing the forwarding of incoming traffic to port 5060 to the service provider address. The whole setup looks a little bit strange (but not necessarily wrong) because the PBX seems to have one public IP address but has a route into private IP addresses. Maybe something went wrong there. Quote Link to comment Share on other sites More sharing options...
sean Posted January 11, 2010 Author Report Share Posted January 11, 2010 Thanx for your feedback, and sorry for my late reply. Extended vacation On the out capture, there is no traffic (at least I did not find anything) that shows the PBX being involved... The attached archive contains two capture-files, one with pbxnsip being involved, one without. All packets in the file ixto_fax_out_pbxnsip.cap contain the pbxnsip (192.168.0.210) either as source or as destination. The files ixto_fax_out_QSC.cap does not contain PBX. This was a test to ensure the general ability of our VOIP-Provider and the ATA to send faxes via T38. Maybe that is the problem? Did you set an outbound proxy on the ATA that points to the PBX? Maybe the ATA tries to go directly to the service provider. When sending through pbxnsip, the ATA has the outbound proxy set to 192.168.0.210(PBX). The other thing that I can think of would be that there is a operating system service performing the forwarding of incoming traffic to port 5060 to the service provider address. The whole setup looks a little bit strange (but not necessarily wrong) because the PBX seems to have one public IP address but has a route into private IP addresses. Maybe something went wrong there. Maybe I should clearify our setup a little bit: All our phones and the pbxnsip are in the privat network 192.168.0.0/24 The pbxnsip does not have a public address. There are no forwarding rules in the Firewall/NAT-GW for incoming VOIP-Traffic. (could this be the problem? does the externel SIP-GW try to establish a new incoming connection for t38 which is then blocked at our firewall/NAT-GW) The pbxnsip has IP 192.168.0.210 The ATA has IP 192.168.0.209 The Standard-Gateway is 192.168.0.1 The SIP-GW of our Provider (QSC) has the IP 213.148.136.2 I just confirmed that the capture-files do reflect this setup. Is there anything wrong with this setup? Could you please reevaluate your analysis of the capture-files? Do you need the files in another format or any additional information to help me solve this problem? Cheers, s. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 11, 2010 Report Share Posted January 11, 2010 The SIP-GW of our Provider (QSC) has the IP 213.148.136.2 Hmm. Any chance to quickly try another provider just to see if that is the problem? Divide and conquer... Or do you have the chance to get a public IP address for the PBX (in addition to the private IP address). That makes it very easy for the provider to give you good SIP trunking service. Quote Link to comment Share on other sites More sharing options...
sean Posted January 22, 2010 Author Report Share Posted January 22, 2010 Hmm. Any chance to quickly try another provider just to see if that is the problem? Divide and conquer... Or do you have the chance to get a public IP address for the PBX (in addition to the private IP address). That makes it very easy for the provider to give you good SIP trunking service. Changing the provider is not really possible here. But since faxing works perfectly, as long as I change only one of the involved parameters (excluding pbx), I don't expect changing the provider would yield any new insight. The same applies to the public IP-address. All our telephony with pbx and SIP-Trunk work perfectly through our NAT-GW. Also faxing works with t38 through our NAT-GW, as long as PBX is not involved. I will try to test with a public IP, but this could not be the final solution. So the captures and logfiles do not offer any clue as to where the problem is? Would additional information help in anyway to solve the problem? Cheers, s. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 23, 2010 Report Share Posted January 23, 2010 Changing the provider is not really possible here.But since faxing works perfectly, as long as I change only one of the involved parameters (excluding pbx), I don't expect changing the provider would yield any new insight. The other thing you can try is to avoid UPDATE. The service provider proposes the usage of UPDATE: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,[b]UPDATE[/b],MESSAGE,REFER However, then the PBX sends an UPDATE request to the service provider, there is no response at all (packet number 120 in the pcap). I guess that is where the communication goes wrong. Much later, there is a requets timeout for the UPDATE (packet 1947). There are actually many devides that advertize UPDATE but don't support it or their support is extremly buggy. Because of that we have changed the UPDATE policy in later versions and by default the PBX does nut use UPDATE any more. Anyway, in your case it seems that usage is still activated. Check the pbx.xml file for "support_update" and change it to false (the easiest is to edit the pbx.xml file and restart the service; you can also do it through the webinterface, see https://www.pbxnsipsupport.com/index.php?_m...barticleid=413). Quote Link to comment Share on other sites More sharing options...
sean Posted January 28, 2010 Author Report Share Posted January 28, 2010 The other thing you can try is to avoid UPDATE. The service provider proposes the usage of UPDATE: First of all: Thank you for your continuing effort to help me solve this problem. As you suggested, I set <support_update> to false. Unfortunateley this did not solve the problem jet. Find attached a little graphic that further illustrates our environment. Option A (green): This is our preferred setup, but the switch to t38 does not seem to work. Find attached two new traffic-captures taken on the pbx itself: A.1: as illustrated the traffic between the ATA and the PBX A.2: Traffic between PBX and the SIP-GW at our provider QSC. Option B (blue): This is the setup not involving the pbx This is the only Setup that works with t38, so far. One capture ( directly at the ATA (through port-mirroring at the switch). I am not really experienced in interpreting SIP-communication, but two things cought my attention, when comparing the working option B with the failing option A: 1) In Frame B.576 an invitation to t38 is issued by the SIP-GW (upstream), and in Frame B.580 it is accepted by the ATA (downstream). The same happens in capture A1 (Frame A1.651 and A1.661) and Capture A2 (Frame A2.59 and A2.70) only here in the opposite direction, i.e. the downstream component (A1=ATA; A2=PBX) is inviting the Upstream componen (A1=PBX; A2=SIP-GW). 2) The Session- and MediaAttributes in the SDP-Frames differ between Option A and B. I do not expect the NAT-GW to be the problem, as the working option B is also going through the NAT-GW. I hope the provided information will help in isolating the problem. Cheers, s. Captures_fax_out.zip Quote Link to comment Share on other sites More sharing options...
sean Posted February 11, 2010 Author Report Share Posted February 11, 2010 Any ideas? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 25, 2010 Report Share Posted February 25, 2010 Seems there is a interop problem with the Huawei. What I can see is that in the successful case the Huawei sends an SDP with both audio amd image and that seems to be fine; however in the case when the PBX is involved there is only image. T.38 is a mess when it comes to interoperability. Maybe the problem will magically go away with the next update of the soft switch (which is not in our control). Right now my recommendation is to keep the setup the way it is any bypass the PBX. BTW the other way to do FAX (secure!) is using https. That is becoming more and more popular and that is very easy when it comes to interop. Quote Link to comment Share on other sites More sharing options...
sean Posted February 26, 2010 Author Report Share Posted February 26, 2010 The Huawei is located at our VOIP-Provider QSC, so we don't have any influence either Right now, we are testing an upgrade to our Firewall/NAT-GW, and first tests look promising. Though I have no clue, why this component should make any difference, since it was involved in the successfull scenario as well. Using https to fax sounds interesting. I will look into it. Cheers, sean Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.