9608 H323 remote extension TCPOpen

[jeepguy267]

Cant find any references to these 2 symptoms:
1. When I login and enter password phone seems to login but then sits with "Phone" showing in the top left corner.
2. In monitor H323 status it shows the phone keeps re-registering with the URQ Reason of "TCPOpen"

The setup:
IP500V2 8.1.73
ports are all allowed and forwarded through sonicwall TZ105:
UDP 1719,TCP 1720
also UDP 1718 as result of reading other posts
UDP 5005,
UDP 49152-53246

h323 remote enabled on LAN1, user, and extension
direct media path disabled
end point license is valid
0.0.0.0 / 0.0.0.0 / GW 192.168.0.1 / LAN1 is only route on system. 192.168.0.1 is Sonicwall
STUN results to multiple STUN servers all show "Port Restricted Cone NAT" with correct public IP. The STUN shows a different "Public Port" UDP port number each time I run it. Not sure what to make of this.

On the remote phone do you bother with setting the http server address?

I never use the LAN1 Primary Trans IP. Should I set the gateway here or my route is good enough?

Thank you, any help is appreciated

 

[nickgrill]

do you have H323 Remote Extn Enable checked under the VOIP tab?

I am having a similar issue. I am connecting a remote 9608 through a sonicwall tz205. phone connects but has no audio. any help would be appreciated.

 

[smokinjoe2938]

(On the remote phone do you bother with setting the http server address?) What type of remote phone do you have? it may be an H.323 so yes you would need to define the ip office as the h.323 server address

acss sme acis sme acss cm 5.2.1 acss cm and cmm acss aura messaging.

 

[jeepguy267]

nickgrill, Yes I have that checked. I brought the remote phone to another location and the phone pulls the button map etc. So I get more than I do at the house. Still no audio, but I'm going to blame the router at the house for my initial trouble. I'm going to see what I can find in the sonicwall forums as the IPO is set as needed per docs. Not much to tweak there. I'll post what I find if anything.

Do you have the IPOffice RTP ports defined as UDP for the protocal in your sonicwall or some other custom protocol number? RTP is not a select-able protocol as far as I can tell.

Do you have constant NAT checked or unchecked in your sonicwall?

 

[tlpeter]

RTP is UDP and yes you must forward those as it is used for speech.

BAZINGA!

I'm not insane, my mother had me tested!

 

[nickgrill]

any new updates on this topic yet? I am still having the no audio issue.

 

[Bas1234]

Enable STUN.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jeepguy267]

Bass1234, stun is set on the IPO. stun results are in my first post.

Nickgrill, Im kinda stuck. The sonicwall is dropping the UDP packets associated with the call traffic. Call setup, touch tones, etc all work fine it's just the audio.

I can see it failing, but not sure what changes to make to fix it:
On the sonicwall the traffic comes in with a source port within the defined range of the sonicwall NAT rules and the IPO range (UDP 49152-53246), but the destination port shows a number outside the range and so the packet is dropped because it doesn't have a NAT rule. Each time I tried a call it used the same port numbers. As a test I expanded my NAT rule up to port number 60000 to incorporate the 58880 that kept showing and as a result the Dst port changed to a completely different number. Set the scope back to 49152-53246 and the 58880 comes up again. What I cant figure is what device is changing the port from 49652 to 58880? It would seem since changing the rule effected the port result that the sonicwall is making the change and then dropping the packet because it doesn't like what it changed it to. weird.

from the log:
Src. IP x.x.x.x (public IP of remote phones gateway)
Src. Port 49652
Src. Int. X1
Dst. IP y.y.y.y (public IP of sonicwall WAN port, X1)
Dst. Port 58880
Dst. Int. X1
Ether Type 2048
Src. MAC ------------------
Src. Zone WAN
Dst. MAC ------------------
Dst. Zone WAN
IP Protocol udp

 

[jeepguy267]

From the IPOffice Monitor application under RTP sessions I see the call with:
source ip 192.168.0.240 (IPO) port 49152
destination ip x.x.x.x (public IP of remote phone gateway) port 49652

So the IPO does see the call with both ports in the correct range. It really does seem like the Sonicwall is changing the port number then dumping it because it is outside of the rule.

 

[jeepguy267]

FIXED!!

I found the below article on sonicwall's support site. Based on this I tinkered with the NAT settings, and disabled/ignored the STUN results. Set my firewall/NAT type to "Symmetric NAT" and made a successful inbound and outbound call with audio. The article is an older document and using the Full Cone setting it recommends did NOT work for me.
---------------------------------------------------------------------
UTM - VoIP: After Upgrading Avaya Firmware from 5.0.8 to 5.0.18 Phones Stop Working
(Article ID: 7769)

Article Applies To:

Affected SonicWALL Security Appliance Platforms:

Gen5: NSA E7500, NSA E6500, NSA E5500, NSA 5000, NSA 4500, NSA 3500, NSA 2400, NSA 240
Gen5 TZ Series: TZ 100, TZ 100 Wireless, TZ 200, TZ 200 W, TZ 210, TZ 210 Wireless,
Gen4: PRO series: PRO 5060, PRO 4100, PRO 4060,PRO 3060, PRO 2040, PRO 1260
Gen4: TZ series: TZ 190, TZ 190 W, TZ 180, TZ 180 W, TZ 170, TZ 170 W, TZ 170 SP, TZ 170 SP Wireless, TZ 150, TZ 150 W, TZ 150 Wireless (RevB)
Gen3: PRO series: PRO 330, PRO 300, PRO 230, PRO 200, PRO 100
SOHO3/TELE3/GX series: SOHOW, SOHO3, TELE3, TELE3 SP, TELE3 TZ, TELE3 TZX, GX 650, GX 250
Firmware/Software Version: All versions.


Problem Definition:

After upgrading the vendor's firmware from 5.0.8 to 5.0.18 the phones will no longer be able to complete calls


Resolution or Workaround: The issue is resolved in the PBX setting

Step 1: On the network setting there will be an option for the type of NATTING
Step 2: Choose Full Cone
Step 3: Our device is a Symetric NATTING device, but Avaya identifies us as "FULL CONE"


How to Test:

After making the changes test the calls