Help! Losing DTMF detection when IP address changes

[Keith]

Hoping for an easy quick fix to this as our system is currently down and folks are unhappy with me :|

Here's our system setup, running on a Mac Mini behind a firewall. We have a fixed public IP and I have opened ports to allow the system and media to come through. system normally runs fine:

Version: 2011-4.5.0.1050 Coma Berenicids (MacOS)

Created on: Apr 2 2012 12:05:17

License Status: snom ONE free

License Duration: Permanent

Additional license information: Extensions: 10/10 Accounts: 25/30 Upgrade: 01 01 2013

Working Directory: /Applications/snomONE/conf

MAC Addresses: -----

DNS Servers: 192.168.0.2 68.87.69.146 68.87.85.98

CDRs: Duration(4d): trunk = 26, extension = 21, ivr = 27

Calls: Total 5/0, Active 0/0 Calls

SIP packet statistics: Tx: 810 Rx: 731

Emails: Successful sent: 1 Unsuccessful attempts: 0

Available file system space: -25%

Uptime: 2012/10/3 10:54:41 (uptime: 0 days 00:44:34) (39329 40346-0) WAV cache: 1

Number of HTTP sessions: Sessions: PAC=0, HTTP=1; Threads: SIP=3, HTTP=1

Domain Statistics: Total Domains: 1, Total Accounts: 25

 

 

Every so often our AA will not recognize key presses of incoming callers, nor detect a hangup signal either. I spoke with our SIP Trunk provider (Braodvox) and they noticed that in our SIP header the IP address of "127.0.0.1" was showing up (which is the localhost address of the PC that our Snom One is running on). They said it should be actually be our public IP address, which is 74.94.xx.xx. Strange thing is, normally the SIP headers DO reflect our public IP number -- then suddenly it'll start referring to the "127.0.0.1" again which renders the DTMF tones unreadable to the system.

 

Is there any way to force our public IP address to appear in the headers always? I have no idea why it suddenly changes. Here's a portion of a logfile below. Any help appreciated, thanks!!

 

[5] 2012/10/03 10:37:33: SIP Rx udp:208.93.227.215:5060:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK-217db88908d0a4f24aaed01ad49ac87e;rport=5060;received=74.94.78.73

From: "2066392700" <sip:2066392700@208.93.227.215>;tag=595505757

To: "2066392700" <sip:2066392700@208.93.227.215>;tag=megFrK331FH4D

Call-ID: bca8s0lj@pbx

CSeq: 2638 REGISTER

Contact: <sip:2066392700@127.0.0.1:5060;transport=udp;line=c81e728d>;+sip.instance="<urn:uuid:dc20d480-3bb1-46b7-a06c-e8f56b912c0e>";expires=30

Date: Wed, 03 Oct 2012 17:37:33 GMT

User-Agent: Broadvox Fusion

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY

Supported: timer, precondition, path, replaces

Content-Length: 0

 

[5] 2012/10/03 10:37:47: Did not receive ACK, disconnecting call abf9b40b-8823-1230-7794-f04da23d7069

[Vodia PBX]

127.0.0.1 does not look healthy. First of all, there must be something going on with the routing table on your host if it uses the loopback interface address on outbound traffic. If you know bash on Mac, "route" is the command that you can use to view the current route configuration.

 

That will probably just get you the private IP address of the PBX, which is usually okay for providers like BroadVox. I would test a few times and see if the private IP address shows up all the time. Maybe your problem is solved already then.

 

If it does not work properly yet, you have to "pretend" that the PBX is running on a public IP address. There is a global settings on the PBX called "IP Routing List" (admin/settings/ports) that you can tweak to manipulate the IP address which are being presented to the outside world. http://wiki.snomone.com/index.php?title=Server_Behind_NAT shows you how to use this setting. But again, I would check first why you see 127.0.0.1, may guess is that this is screwing things up.

[Keith]

Thanks so much for your reply.

 

I did try making entries into the 'SIP IP Replacement List' and was getting frustrated since it didn't seem to make any difference in what was being shown in the Logfile.

Then, the system somehow fixed itself in the sense that it went back to using the internal IP address of the computer the PBX runs on (as opposed to the 127.0.0.1). Why, I have no idea -- and that bothered me because I would have to assume it could flip back again at some point.

 

Anyway, today I remembered that you have to restart the PBX in order for those IP Replacements to take hold (Doh!) -- so I made 2 entries there telling the system to replace both the PBX PC local address with our public address as well as the same for 127.0.0.1. Looking at the logfile I can see this is working (our public IP address is now being shown instead of our internal ones) and I feel more secure about things.

 

Thanks!