Jump to content

Send Fax: No CED received through pbxnsip


sean
 Share

Recommended Posts

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

post-891-1259937777_thumb.png

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...
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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 (B) 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.

post-891-1264687566_thumb.jpg

Captures_fax_out.zip

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...