• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Fax server problem ** SOLUTION PROVIDED

Status
Not open for further replies.

lneblett

Joined
Sep 7, 2010
Messages
2,083
Reaction score
72
Any help appreciated -

1. Firewall checker shows OK, however does not seem to address anything to do with port 10000. Port 10000 for both TCP & UDP, both inbound and outbound, are forwarded to internal 3CX server (seems to be indicated below per reinvite request).
2. FaxDIRECTSDP variable set to "1"
3. 3CX Fax Server Provisioning templates (both) modified according to 12.1.2009 FAX over VOIP document in blog
(tested both in original and modified formats)
4, Fax extension "888" shows registered during testing. System stopped and restarted after any change to ensure correct attributes loaded.
5. Voip provider - "NexVortex" , cited as tested/approved t38 carrier.
6. STUN is "Off"
7. Voice calls (internal and external) all work just fine.

Have been unble to get fax machines to connect. Can hear tones from each, but connection never established.

Nexvortex advised -
"Your T.38 codec reinvite contained a private IP address in the SDP data:
c=IN IP4 192.168.0.250..t=0 0..m=image 10000 udptl t38..a=T38FaxVersion
:0..a=T38MaxBitRate:14400..a=T38FaxRateManagement:transferredTCF..a=T38FaxM
axBuffer:10500..a=T38FaxMaxDatagram:1500..a=T38FaxUdpEC:t38UDPRedundancy..

The NAT translation in your 3CX configuration needs to be corrected. The c= string must ALWAYS contain the public IP address of your network."

I had assumed that a change of this type would be covered in the provisioning template changes covering NAT. I have stated both the local and public IP addresses as indicated in the blog document.

I can include logs if needed, but Nexvortex seemingly has identified the issue, and it is now a question of how to get the reinvite to point to the public Ip rather then the local.

Anyone using NexVortex with fax and having success? Can you share what you ended up doing?

Thanks in advance.
 
Re: Fax server problem

You have to configure 3CX FAX SERVER for NAT. If you open the Fax cfg files there, there are comments that you need to uncomment and update.

C:\ProgramData\3CX\Data\Fax\Cfg

there are 2 files - open and read them. They should be self explanatory.

I work with nexvortex and fax without making these changes. Maybe you need to do them - it is worth a try.

Question for you - does a normal AUDIO Call also send the private ip instead of the public ip? Because then there is another problem not related to fax.
 
Nick -

Thanks for the response, but as stated in the post, I have tried both with and without NAT by using the config files unmodified and modified as indicated in the blog covering fax over ip to no avail. I have escalated to support. No matter what the config file indicates, I seem unable to change the connect (c=) address to reflect the public IP.

Wireshark shows that voice calls do indeed have a connection request (C=) to the public IP. The only thing I see that sticks out is that voice calls do not have a reinvite whereas fax (t38) does and this is when the private IP comes in rather than the public. I have provided data flows and captures of the issue in the partner forum and to support.

Hopefully, it will be found to be something stupid that I did.

Nevertheless, I do appreciate the response as it does show that there is concern about helping and making 3CX an even better product.

Regards,
Larry Neblett
N2 Tech Solution
 
We will trace the support request you put in support and we will get back to you. Thanks for your update. Can you send your ticket id here?
 
Here is the ticket - 3CXUSA #NXR-911068

I have pasted a couple of wireshark captures following, but what I did here was to implement a call to the main number and then input the fax extension (888). These represent the initial invite and subsequent invite (t38) from 3CX to NexVortex.

Initial invite:
No. Time Source Destination Protocol Info
90 6.427470 192.168.x.xxx 66.23.129.253 SIP/SDP Status: 200 OK, with session description

Frame 90: 1036 bytes on wire (8288 bits), 1036 bytes captured (8288 bits)
Ethernet II, Src: IntelCor_9f:94:2e (00:15:17:9f:94:2e), Dst: Netgear_cc:40:28 (00:24:b2:cc:40:28)
Internet Protocol, Src: 192.168.x.xxx (192.168.x.xxx), Dst: 66.23.129.253 (66.23.129.253)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxPS 343278616576 495213084673 IN IP4 97.79.XXX.XXX
Session Name (s): 3cxPS Audio call
Connection Information (c): IN IP4 97.79.XXX.XXX
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 97.79.XXX.XXX
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 9002 RTP/AVP 0 8 18 101
Connection Information (c): IN IP4 97.79.XXX.XXX
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 97.79.XXX.XXX
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv

2nd Invite

No. Time Source Destination Protocol Info
1215 15.845402 192.168.x.xxx 66.23.129.253 SIP/SDP Request: INVITE sip:[email protected]:5060, in-dialog, with session description

Frame 1215: 1016 bytes on wire (8128 bits), 1016 bytes captured (8128 bits)
Ethernet II, Src: IntelCor_9f:94:2e (00:15:17:9f:94:2e), Dst: Netgear_cc:40:28 (00:24:b2:cc:40:28)
Internet Protocol, Src: 192.168.x.xxx (192.168.x.xxx), Dst: 66.23.129.253 (66.23.129.253)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:[email protected]:5060 SIP/2.0
Message Header
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxPS 434647334912 378275889154 IN IP4 97.79.XXX.XXX
Session Name (s): 3cxPS Audio call
Connection Information (c): IN IP4 192.168.x.xxx
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.x.xxx
Time Description, active time (t): 0 0
Media Description, name and address (m): image 10000 udptl t38
Media Attribute (a): T38FaxVersion:0
Media Attribute (a): T38MaxBitRate:14400
Media Attribute (a): T38FaxRateManagement:transferredTCF
Media Attribute (a): T38FaxMaxBuffer:10500
Media Attribute (a): T38FaxMaxDatagram:1500
Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy

You will note the connection information differs between the voice and fax. The voice has the public Ip and the fax the private. This also shows that the first packet is voice given the media attributes (rtp) while the second packet is fax (t38). I did it this way in order to simplify the capture and more accurately show the trail. I have the fax set-up for DID, but the only difference is that when dialing DID, it is a reinvite rather than an invite. The above was all accomplished on a single call

By the way, the config files were in their original state (not modified) during this test, but prior testing with modified files does not seem to make a difference. The faxdirectsdp setting is set to "1". I have also tried to set the faxservershost setting to both the private and public Ip without success (no change in captures noted).

Regards,
Larry
 
So you are calling the main number first - and what answers you at that point before you dial 888?
 
The IVR answers, I input the extension, a tranfer is completed, and I then hear the fax tones. However, keep in mind that I only dialed the main number just for this exercise.

I had included data flow and details in the ticket which was all done using the DID rather than with a transfer.

I am still toying around with it.

Thanks,
Larry
 
I guessed there was an ivr in between but I did not want to jump to conclusions.

No this is not supported. The IVR Automatically binds to media server because it is an internal 3CX Component.

So faxes will never work like this. No wonder you have a private ip in there. This is an unsupported scenario and scenarios like these lead us to wild goose chases. For the future explain the call scenario at the start of a support request because we know what can work and what cannot. Like this we will be faster to reach a solution.

To test this you have to have a DID or the nexvortex line that DIRECTLY forwards to 888 or a Fax device or email of extension.

Always test simple scenario. And this is not only complex for fax, but also not usable. How is a caller going to know that company's ABC's fax extension is 888 of 8545 or whatever? And what is the point of sending a fax through an ivr? Send it directly to a fax number. Yes this is debatable but with fax keep this in mind. Always least hops. Put nothing in between.
 
Nick, please read the post again. I clearly stated that I did the IVR method only for that post, but that the system is indeed set-up for DID and forwards to the email of extension 888. All other posts, except the one noted, use DID. Fax macnines have the capability of putting in pauses such that extensions can be used for those businesses that prefer not to have the expense of a dedicated line/number. You simply inform the sender of the number (as normal) and advise the extension and pause requirements. In any event, I now know. Thanks.

Rest assured however that even when the DID is used, the C= in the reinvite for t38 points to the private Ip rather than the public. I was cutting and pasting the log when I suddenly discovered the following:

10:18:59.460 [CM503004]: Call(37): Route 1: @[Dev:sip:[email protected]:5100;user=phone
10:18:59.460 [CM503010]: Making route(s) to <sip:[email protected]:5060;user=fax>

Please note the address above. The subnet (20) is incorrect and does not reflect the NIC address that is specified anywhere in the 3CX system. This NIC is present in the hardware, but is used to support a public wi-fi network within the building. I am uncertain if this may have an impact on the issue or not. The NIC is selectable in the box for the fax interface but is not the one specified.

Further, I disabled the 20 subnet NIC and restarted the fax server service. The service registered the extension and the log shows thusly:
12:38:15.405 [CM504008]: Fax Service: registered as sip:[email protected]:5060 with contact
sip:[email protected]:5100;user=phone

I then dialed the fax using DID and the log shows:
12:41:33.791 [CM503001]: Call(1): Incoming call from +19564254764@(Ln.10001@NexVortex) to <sip:[email protected]:5060;user=fax>
What is odd is that when the NIC device is disabled, it is no longer selectable as the network interface; yet the 3CX system somehow is able to use the address in its log messaging. I have no clue as to the significance.

The real issue I think is how the reinvite should look. Should it not contain the public IP as NexVortex contends?
 
disable the network and try and re-register nexvortex. (open nexvortex account and click on apply ok.)

Make test again.

If it is still wrong, (keep nic disabled) restart all services including configuration services. (Restart ALL)

Wait for components to register and try again.
 
I did as you suggested.

The log for the initial suggestion is as follows:
16:57:55.476 [CM503008]: Call(84): Call is terminated
16:57:38.961 [CM503007]: Call(84): Device joined: sip:[email protected]:5100;user=phone
16:57:38.960 [CM503007]: Call(84): Device joined: sip:[email protected]:5060
16:57:38.900 [CM503025]: Call(84): Calling @[Dev:sip:[email protected]:5100;user=phone]
16:57:38.870 [CM503004]: Call(84): Route 1: @[Dev:sip:[email protected]:5100;user=phone]
16:57:38.868 [CM505003]: Provider:[NexVortex] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
16:57:38.864 [CM503001]: Call(84): Incoming call from +19564254764@(Ln.10001@NexVortex) to <sip:[email protected]:5060;user=fax>16:57:38.845 [CM503012]: Inbound any hours rule (19564124113*) for 10001 forwards to Fax:888
16:57:19.829 [CM503008]: Call(83): Call is terminated
16:57:03.670 [CM504004]: Registration succeeded for: 10001@NexVortex
16:57:03.389 [CM504003]: Sent registration request for 10001@NexVortex
16:57:03.373 [EC100007]: External application is connected: application:Dolly:0/InterfaceWindows local:127.0.0.1:5482 remote:127.0.0.1:56410
16:56:36.416 [CM503007]: Call(83): Device joined: sip:[email protected]:5060
16:56:26.167 IP(s) removed:[192.168.20.250]

As you can see this did not work.

I then tried the second suggestion and left disabled and restarted all. here is the log:

17:11:19.649 [CM505003]: Provider:[NexVortex] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
17:11:14.548 [MS211000] C:1.1: 4.55.5.130:27160 is delivering DTMF using RTP payload (RFC2833). In-Band DTMF tone detection is disabled for this call segment.
17:11:03.176 [CM504001]: Ext.102: new contact is registered. Contact(s): [sip:[email protected]:52392;rinstance=cac51ea1017328eb/102]
17:10:56.510 [CM504001]: Ext.118: new contact is registered. Contact(s): [sip:[email protected]:5060/118]
17:10:49.922 [CM503007]: Call(1): Device joined: sip:[email protected]:40600;rinstance=586970e6227bbbe9
17:10:49.921 [CM503007]: Call(1): Device joined: sip:[email protected]:5060
17:10:49.717 [CM503025]: Call(1): Calling Ext:Ext.800@[Dev:sip:[email protected]:40600;rinstance=586970e6227bbbe9]
17:10:49.678 [CM503004]: Call(1): Route 1: Ext:Ext.800@[Dev:sip:[email protected]:40600;rinstance=586970e6227bbbe9]
17:10:49.676 [CM505003]: Provider:[NexVortex] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
17:10:49.672 [CM503001]: Call(1): Incoming call from +19562446762@(Ln.10001@NexVortex) to <sip:[email protected]:5060>
17:10:49.617 [CM503012]: Inbound out-of-office hours rule (unnamed) for 10001 forwards to DN:800
17:10:44.892 [CM504001]: Ext.107: new contact is registered. Contact(s): [sip:[email protected]:5060;transport=udp/107]
17:10:21.651 [CM504001]: Ext.112: new contact is registered. Contact(s): [sip:[email protected]:5060/112]
17:10:15.699 [CM504001]: Ext.IVRForward: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=1e73391a5afdc56e/IVRForward]
17:10:15.610 [CM504001]: Ext.EndCall: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=1497f049fb0ac94f/EndCall]
17:10:15.603 [CM504001]: Ext.800: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=586970e6227bbbe9/800]
17:10:15.597 [CM504001]: Ext.999: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=2751f16b6e017d08/999]
17:09:57.700 [CM504001]: Ext.114: new contact is registered. Contact(s): [sip:[email protected]:5060;transport=udp/114]
17:09:53.238 [CM504004]: Registration succeeded for: 10001@NexVortex
17:09:52.880 [CM504003]: Sent registration request for 10001@NexVortex
17:09:52.770 IP(s) added:[192.168.0.250]
17:09:50.930 [CM504001]: Ext.*1: new contact is registered. Contact(s): [sip:*[email protected]:40000;rinstance=04e239a867291f77/*1]
17:09:50.836 [CM504001]: Ext.*0: new contact is registered. Contact(s): [sip:*[email protected]:40000;rinstance=1afaad97cc5e7939/*0]
17:09:50.820 [CM504001]: Ext.*777: new contact is registered. Contact(s): [sip:*[email protected]:40000;rinstance=1bf24407aac53df8/*777]
17:09:45.658 [EC100007]: External application is connected: application:Dolly:0/QueueManager local:127.0.0.1:5482 remote:127.0.0.1:56954
17:09:45.105 [CM504008]: Fax Service: registered as sip:[email protected]:5060 with contact sip:[email protected]:5100;user=phone
17:09:45.074 [CM504004]: Registration succeeded for: 10001@NexVortex
17:09:44.871 [CM504003]: Sent registration request for 10001@NexVortex
17:09:44.575 [EC200002]: Media server is connected: application:Dolly:0/MediaServer local:127.0.0.1:5482 remote:127.0.0.1:56951
17:09:44.497 [EC200005]: Parking Orbit server is connected: application:Dolly:0/3CXParkOrbit local:127.0.0.1:5482 remote:127.0.0.1:56950
17:09:44.450 [EC200004]: IVR server is connected: application:Dolly:0/IVRServer local:127.0.0.1:5482 remote:127.0.0.1:56947
17:09:44.372 [EC200006]: Conference server is connected: application:Dolly:0/3CXConferenceRoom local:127.0.0.1:5482 remote:127.0.0.1:56945
17:09:43.764 [CM506005]: Public IP=97.79.XX.XXX is used for WAN communications through local interface with IP=192.168.0.250
17:09:42.718 Failed to obtain short path name for [C:\ProgramData\3CX\Bin\Cert]
17:09:42.718 [CM501006]: Default Local IP address: [192.168.0.250]
17:09:42.718 [CM501002]: Version: 9.0.15776.0
17:09:42.718 [CM501001]: Start 3CX PhoneSystem Call Manager
17:09:42.718 [CM501007]: *** Started Calls Controller thread ***
17:09:42.594 [EC200001]: Configuration server is connected: application:Dolly:5485/DBProvider local:127.0.0.1:56942 remote:127.0.0.1:5485
17:09:42.578 [CM501010]: License Info: Load Failed

What is interesting here is that the license failed to load. While the 888 fax extension is shown to be registered by 3CX in the log and in the system extension status page, a call to the DID number gives a playback indicating the that service is not registered. Further, the conference extensions and shared park extensions also show as not registered. All the 3CX services show to be started in both 3CX and Windows Server 2008 Services. I assume the software has implemented the free addition attributes as a result of not being able to load the license info. I then killed them all and restarted again while the NIC was disabled and the same results.

I then renabled the second NIC and all started up upon a restart all. However, as you can see, 3CX picked up the second NIC card....again.

Following is the log.

17:32:58.598 [CM504001]: Ext.118: new contact is registered. Contact(s): [sip:[email protected]:5060/118]
17:32:44.287 [CM504001]: Ext.102: new contact is registered. Contact(s): [sip:[email protected]:52392;rinstance=cac51ea1017328eb/102]
17:32:36.070 [CM504001]: Ext.106: new contact is registered. Contact(s): [sip:[email protected]:5060/106]
17:32:33.802 [CM504001]: Ext.105: new contact is registered. Contact(s): [sip:[email protected]:5060/105]
17:32:29.335 [CM504001]: Ext.MakeCall: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=f69e732b3f3248aa/MakeCall]
17:32:29.334 [CM504001]: Ext.IVRForward: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=3b00e63a2229a2fa/IVRForward]
17:32:29.321 [CM504001]: Ext.EndCall: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=c42e071523fe35e2/EndCall]
17:32:29.312 [CM504001]: Ext.800: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=3bd7041913e5d8ab/800]
17:32:29.199 [CM504001]: Ext.999: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=1879b2c9bd97287e/999]
17:32:07.086 [CM504004]: Registration succeeded for: 10001@NexVortex
17:32:06.739 [CM504003]: Sent registration request for 10001@NexVortex
17:32:06.635 IP(s) added:[192.168.20.250,192.168.0.250]
17:32:04.560 [CM504001]: Ext.SP9: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=0576b430607fdbb6/SP9]
17:32:04.560 [CM504001]: Ext.SP8: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=e78c223278eaeab5/SP8]
17:32:04.559 [CM504001]: Ext.SP7: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=4764bf064e08f297/SP7]
17:32:04.558 [CM504001]: Ext.SP6: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=50af06e8b3579bcf/SP6]
17:32:04.545 [CM504001]: Ext.SP5: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=c254a64c684bf152/SP5]
17:32:04.525 [CM504001]: Ext.SP4: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=fb318658291ba2c2/SP4]
17:32:04.513 [CM504001]: Ext.SP3: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=d03e3535fecad60f/SP3]
17:32:04.424 [CM504001]: Ext.SP2: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=46a180be52fa7937/SP2]
17:32:04.423 [CM504001]: Ext.SP1: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=36e7e1c69bfec016/SP1]
17:32:04.422 [CM504001]: Ext.SP0: new contact is registered. Contact(s): [sip:[email protected]:40000;rinstance=36e782e83b7e6baf/SP0]
17:32:04.410 [CM504001]: Ext.*1: new contact is registered. Contact(s): [sip:*[email protected]:40000;rinstance=6edba88e24795027/*1]
17:32:04.397 [CM504001]: Ext.*0: new contact is registered. Contact(s): [sip:*[email protected]:40000;rinstance=61c73aaa0091b9da/*0]
17:32:04.388 [CM504001]: Ext.*777: new contact is registered. Contact(s): [sip:*[email protected]:40000;rinstance=1fc75af7538afe81/*777]
17:32:04.365 [CM504001]: Ext.704: new contact is registered. Contact(s): [sip:[email protected]:40300;rinstance=85c89556a88e742b/704]
17:32:04.329 [CM504001]: Ext.703: new contact is registered. Contact(s): [sip:[email protected]:40300;rinstance=c2fb28e603e80570/703]
17:32:04.328 [CM504001]: Ext.702: new contact is registered. Contact(s): [sip:[email protected]:40300;rinstance=a732292cc0e3d7a6/702]
17:32:04.315 [CM504001]: Ext.701: new contact is registered. Contact(s): [sip:[email protected]:40300;rinstance=198ca78873bbadbc/701]
17:32:04.307 [CM504001]: Ext.700: new contact is registered. Contact(s): [sip:[email protected]:40300;rinstance=fcc9d960e68a34ee/700]
17:31:59.461 [EC100007]: External application is connected: application:Dolly:0/QueueManager local:127.0.0.1:5482 remote:127.0.0.1:57596
17:31:58.990 [CM504004]: Registration succeeded for: 10001@NexVortex
17:31:58.844 [CM504008]: Fax Service: registered as sip:[email protected]:5060 with contact sip:[email protected]:5100;user=phone
17:31:58.703 [CM504003]: Sent registration request for 10001@NexVortex
17:31:58.336 [EC200002]: Media server is connected: application:Dolly:0/MediaServer local:127.0.0.1:5482 remote:127.0.0.1:57592
17:31:58.284 [EC200005]: Parking Orbit server is connected: application:Dolly:0/3CXParkOrbit local:127.0.0.1:5482 remote:127.0.0.1:57591
17:31:58.214 [EC200004]: IVR server is connected: application:Dolly:0/IVRServer local:127.0.0.1:5482 remote:127.0.0.1:57588
17:31:58.137 [EC200006]: Conference server is connected: application:Dolly:0/3CXConferenceRoom local:127.0.0.1:5482 remote:127.0.0.1:57586
17:31:57.599 [CM506005]: Public IP=97.79.xxx.xxx is used for WAN communications through local interface with IP=192.168.0.250
17:31:56.545 Failed to obtain short path name for [C:\ProgramData\3CX\Bin\Cert]
17:31:56.545 [CM501006]: Default Local IP address: [192.168.20.250, 192.168.0.250]
17:31:56.544 [CM501002]: Version: 9.0.15776.0
17:31:56.544 [CM501001]: Start 3CX PhoneSystem Call Manager
17:31:56.544 [CM501007]: *** Started Calls Controller thread ***
17:31:56.421 [EC200001]: Configuration server is connected: application:Dolly:5485/DBProvider local:127.0.0.1:57581 remote:127.0.0.1:5485
17:31:56.406 [CM501009]: License Info: Loaded Succeeded
 
Nicky,

I should also point out that the 2nd NIC card is not configured with a gateway or DNS servers. This card is used to connect to the wireless access points on the open wi-fi network (local only) for configuration reasons. It does not have internet connectivity by itself. This aspect (wi-fi) of the network was implemented after the 3CX system was installed.

Prior to the wi-fi being implemented, the same card was configured into the system and did have a private IP on the same subnet. It was previously being used as a dedicated link to a NAS for backup. This was in place when the 3CX system was installed.

Thanks,
Larry
 
keep the second nic card disabled. and fix 17:09:42.578 [CM501010]: License Info: Load Failed

Restart the machine and reactivate the license. It seems that that second nic was the preferred route and had a higher metric than the other.

Get the licence activated and working on the 1 production nic - leave the other disabled. We have too many loose ends like this and we have to try and minimize ANYTHING that can cause the LEAST issue. A second nic in this scenario is overkill for fax.

I want 3CX to have 1 nic. I want j3CX to activate and license with 1 nic.
Go to the Fax interface, select the nic and press APPLY OK.

To confirm that the FAX service is buond to that network interface open this log file located here :
C:\ProgramData\3CX\Bin\3CXLogger.ini
Scroll at the bottom
and in the fax server node you should see the interface there.
Example
[Fax]
ServerHost=x.x.x.x

let me know results of the test after this.
 
Nicky,

Did as you suggested and restarted system with 2nd NIC disabled. Applied fax interface to NIC of interest. Confirmed that 1st NIC is bound to fax and had to reactivate license, which was successful as it did indeed revert to free version. This seems to have fixed the 2 NIC issue for the moment. I have not reactivated the 2nd NIC as of yet and will leave disabled until we get issues resolved. I then tested fax using DID with following log results:

06:06:06.541 [CM503008]: Call(6): Call is terminated
06:05:20.790 [CM503007]: Call(6): Device joined: sip:[email protected]:5100;user=phone
06:05:20.788 [CM503007]: Call(6): Device joined: sip:[email protected]:5060
06:05:20.727 [CM503025]: Call(6): Calling @[Dev:sip:[email protected]:5100;user=phone]
06:05:20.684 [CM503004]: Call(6): Route 1: @[Dev:sip:[email protected]:5100;user=phone]
06:05:20.683 [CM505003]: Provider:[NexVortex] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]
06:05:20.679 [CM503001]: Call(6): Incoming call from +19564254764@(Ln.10001@NexVortex) to <sip:[email protected]:5060;user=fax>
06:05:20.674 [CM503012]: Inbound any hours rule (19564124113*) for 10001 forwards to Fax:888
06:03:54.779 [CM503007]: Call(5): Device joined: sip:[email protected]:5060
06:03:54.656 [CM503004]: Call(5): Route 1: @[Dev:sip:[email protected]:5100;user=phone]
06:03:54.650 [CM503001]: Call(5): Incoming call from +19564254764@(Ln.10001@NexVortex) to <sip:[email protected]:5060;user=fax>

The last action appears to have been successful in associated the fax service to the desired NIC. Unfortunately, the Wireshark capture still seems to be using the private IP on the reinvite.

Frame 41: 1016 bytes on wire (8128 bits), 1016 bytes captured (8128 bits)
Ethernet II, Src: IntelCor_9f:94:2e (00:15:17:9f:94:2e), Dst: Netgear_cc:40:28 (00:24:b2:cc:40:28)
Destination: Netgear_cc:40:28 (00:24:b2:cc:40:28)
Source: IntelCor_9f:94:2e (00:15:17:9f:94:2e)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.250 (192.168.0.250), Dst: 66.23.129.253 (66.23.129.253)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:[email protected]:5060 SIP/2.0
Method: INVITE
Request-URI: sip:[email protected]:5060
[Resent Packet: False]
Message Header
Via: SIP/2.0/UDP 192.168.0.250:5060;branch=z9hG4bK-d8754z-56435a16a906e412-1---d8754z-;rport
Max-Forwards: 70
Route: <sip:[email protected]:5060;lr;nat=yes;ftag=gK04778fc4>
Contact: <sip:[email protected]:5060>
Contact-URI: sip:[email protected]:5060
Contactt-URI User Part: 19564124113
Contact-URI Host Part: 97.79.xxx.xxx
Contact-URI Host Port: 5060
To: "NEBLETT,LARRY"<sip:[email protected]:5060>;tag=gK04778fc4
SIP Display info: "NEBLETT,LARRY"
SIP to address: sip:[email protected]:5060
SIP to address User Part: +19564254764
SIP to address Host Part: 4.55.5.163
SIP to address Host Port: 5060
SIP tag: gK04778fc4
From: <sip:[email protected]:5060>;tag=5d720e0d
SIP from address: sip:[email protected]:5060
SIP from address User Part: +19564124113
SIP from address Host Part: 66.23.129.253
SIP from address Host Port: 5060
SIP tag: 5d720e0d
Call-ID: [email protected]
CSeq: 2 INVITE
Sequence Number: 2
Method: INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 9.0.15776.0
Content-Length: 301
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxPS 389399183360 541081993218 IN IP4 97.79.xxx.xxx
Owner Username: 3cxPS
Session ID: 389399183360
Session Version: 541081993218
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 97.79.xxx.xxx
Session Name (s): 3cxPS Audio call
Connection Information (c): IN IP4 192.168.0.250
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.0.250
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): image 10000 udptl t38
Media Type: image
Media Port: 10000
Media Protocol: udptl
Media Format: t38
Media Attribute (a): T38FaxVersion:0
Media Attribute Fieldname: T38FaxVersion
Media Attribute Value: 0
Media Attribute (a): T38MaxBitRate:14400
Media Attribute Fieldname: T38MaxBitRate
Media Attribute Value: 14400
Media Attribute (a): T38FaxRateManagement:transferredTCF
Media Attribute Fieldname: T38FaxRateManagement
Media Attribute Value: transferredTCF
Media Attribute (a): T38FaxMaxBuffer:10500
Media Attribute Fieldname: T38FaxMaxBuffer
Media Attribute Value: 10500
Media Attribute (a): T38FaxMaxDatagram:1500
Media Attribute Fieldname: T38FaxMaxDatagram
Media Attribute Value: 1500
Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
Media Attribute Fieldname: T38FaxUdpEC
Media Attribute Value: t38UDPRedundancy

So, the connection c=in information remains unchanged. Note that the owner info all appears OK.

Now then, what also now appears is that upon the initial invite from 3CX, the connect c= info is also reporting the same private IP. The frame above is Frame 41 (the reinite for fax) whereas the frame following is Frame 15, the initial 3CX invite.

Frame 15: 902 bytes on wire (7216 bits), 902 bytes captured (7216 bits)
Ethernet II, Src: IntelCor_9f:94:2e (00:15:17:9f:94:2e), Dst: Netgear_cc:40:28 (00:24:b2:cc:40:28)
Destination: Netgear_cc:40:28 (00:24:b2:cc:40:28)
Source: IntelCor_9f:94:2e (00:15:17:9f:94:2e)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.250 (192.168.0.250), Dst: 66.23.129.253 (66.23.129.253)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: False]
[Request Frame: 2]
[Response Time (ms): 214]
Message Header
Via: SIP/2.0/UDP 66.23.129.253:5060;branch=z9hG4bK21e1.552eb117.0
Via: SIP/2.0/UDP 4.55.5.163:5060;branch=z9hG4bK04B9d3d529852e9c049
Record-Route: <sip:[email protected]:5060;lr;nat=yes;ftag=gK04778fc4>
Contact: <sip:[email protected]:5060>
Contact-URI: sip:[email protected]:5060
Contactt-URI User Part: 19564124113
Contact-URI Host Part: 97.79.xxx.xxx
Contact-URI Host Port: 5060
To: <sip:[email protected]:5060>;tag=5d720e0d
SIP to address: sip:[email protected]:5060
SIP to address User Part: +19564124113
SIP to address Host Part: 66.23.129.253
SIP to address Host Port: 5060
SIP tag: 5d720e0d
From: "NEBLETT,LARRY"<sip:[email protected]:5060>;tag=gK04778fc4
SIP Display info: "NEBLETT,LARRY"
SIP from address: sip:[email protected]:5060
SIP from address User Part: +19564254764
SIP from address Host Part: 4.55.5.163
SIP from address Host Port: 5060
SIP tag: gK04778fc4
Call-ID: [email protected]
CSeq: 29610 INVITE
Sequence Number: 29610
Method: INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: 3CXPhoneSystem 9.0.15776.0
Content-Length: 186
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 3cxPS 389399183360 541081993217 IN IP4 97.79.xxx.xxx
Owner Username: 3cxPS
Session ID: 389399183360
Session Version: 541081993217
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 97.79.xxx.xxx
Session Name (s): 3cxPS Audio call
Connection Information (c): IN IP4 192.168.0.250
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.0.250
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 10002 RTP/AVP 0
Media Type: audio
Media Port: 10002
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute Fieldname: rtpmap
Media Format: 0
MIME Type: PCMU
Sample Rate: 8000
Media Attribute (a): maxptime:20
Media Attribute Fieldname: maxptime
Media Attribute Value: 20
Media Attribute (a): sendrecv


Nexvortex acks the initial invite (frame 15) which is when 3CX sends out the t38 invite (frame 41). I have attached the flow datagram.
 
I suggest we continue supporting your case in the support portal. Forum thread is getting clunky now.

YOu deal with support.
In the meantime I will test nexvortex with fax and we will update each other from there.

Send me an email [email protected] with your wireshark capture showing a failure so I know your contact and can advise you with my results.
 
I have this same problem, did it turn out to be the 3cx server not handling the nat, or did the gateway need proxy settings?
I have my patton m-ata set to use a fax server extension, and have left the nat proxy settings to none under the sip configuration(however I tried the settings under the config with port 5100, and ports 10000 with the internal address of my 3cx server, and none of those worked)
I also tried the 3cx stun server, yet the c= was still populated with the internal address of the patton gateway.

I'm not sure if it is a patton problem, or 3cx at this point...at least nexvortex has been very helpful!
 
*********patton support response****
my question:
Clarification on use with nat
Nexvortex has traced the issue to a nat problem. The internal address of the patton is getting populated in a field
C=IN IP4 x.x.x.x, when that is supposed to be a nat field from the 3cx server.
Should I be configuring a sip proxy under the sip settings(is that field usually populated by the patton, or is our 3cx server supposed to handle nat’ing that field?)

response:

====== Please reply above this line ======
Hi,
Generally there would be a router performing NAT to get calls to and from the private to public networks, and not the M-ATA. 3CX wouldn't be doing it either, but some router on the network.

Regards,

Steve Gardner
Technical Support Engineer

Patton Electronics
http://patton.com
http://support.patton.com - Patton Support
+1 (301) 975-1007


Ticket Details
________________________________________
Ticket ID: 88023
Department: Support for NA/LA/APAC
Type: Issue
Status: Waiting for Response
Priority: Standard
 
I just wanted to add a note to this thread, that we indeed had to have the NAT configuration for Nexvortex to receive faxes to the 3cx fax server over a DID. We are still troubleshooting our patton gateways, however we aren't completely dead in the water for incoming fax now.
 
When you say NAT configuration you mean you needed to modify the FAX CFG files for NAT correct?
 
Status
Not open for further replies.

Getting Started - Admin

Latest Posts

Forum statistics

Threads
141,611
Messages
748,810
Members
144,721
Latest member
jabren
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.