[cisco-voip] ATA talking to itself through MSFT h.323/firewall

[Roland H. Alden]

This has me puzzled but I'm a newbie at this. Hopefully my error is obvious to someone.

I have two brand new Cisco ATA 188's loaded with [Version: v3.1.0 atah323 (Build 040219A)].

I am using Microsoft's H.323 gateway which is part of their firewall product called "ISA Server" (ISA for short). It is a classic firewall that does NAT, has an "inside" and "outside" and had a fair amount of stuff filtering/editing traffic flows including a special "h.323 filter" that is supposed to be smart about h.323. It also has an h.323 gatekeeper/gateway that will accept registrations and direct traffic from e.164 or RFC822 identifiers to IP addresses it knows about, including those in the inside network.

I've tested the following configurations:

1. Both ATA's are on the inside of ISA, both register with ISA and calls can be made between them using e.164 addresses. No problem. Works great.

2. One ATA is on the inside and one ATA is on the outside. There is NAT and the firewall between them. The inside ATA registers to the "GkOrProxy" service provided by ISA using the private IP address. The outside ATA does the same using the outside IP address of the ISA server. Both register with ISA and calls can be made between them using e.164 addresses. The phones ring and can be answered; BUT no audio goes in either direction. Using prserv as a debug tool I can see that the connection is made and it does not appear that any codec negotiation takes place (see traces below). These audio less calls will hang up on themselves after about a minute or two.

3. One ATA is on the inside and one instance of Microsoft Netmeeting is on the outside. Just as in the above case both register fine and calls can be placed between them using e.164 numbers. Amazingly, audio works both ways in this case.

The surprise (to me) here is that I'd expect the ATA's to interoperate with each other and the ATA-Netmeeting session to be the troublemaker. Clearly the ATA's can talk to each other as long as they are not separated by NAT and one of them can be behind a firewall/NAT and talk through NAT to a Netmeeting instance on the outside. So, I'm puzzled as to why it can't talk to "itself" over the same path but can talk to Netmeeting.

Here's a snip of a prserv log:

14157474101 active @0x441d809 (GK @0xd1ea6112)
[0]StartTone 0
[0]DTMF 1 , insum:651454
[0]StopTone
[0]DTMF 7 , insum:611996
[0]DTMF 6 , insum:623313
[0]DTMF 0 , insum:627534
[0]DTMF 7 , insum:646051
[0]DTMF 4 , insum:660617
[0]DTMF 7 , insum:610264
[0]DTMF 4 , insum:660703
[0]DTMF 1 , insum:629564
[0]DTMF 0 , insum:611279
[0]DTMF 3 , insum:633347
Calling 17607474103
SCC->(0 0) <cmd 16>
CLIP
SCC->(0 0) <cmd 2>
<0 0> dial<17607474103>
GK<-0: ARQ: 0
GK->0: ACF:0:direct call
IRR in 31 sec
CallRasCallBack: 1 33e197f 33e251e 33e3fd5
Connect to <0x421b150 1720>..
>>>>>>>> TX CALLER ID : 0x1 0x80 13
Q931<-0:Setup:CRV 18229
Q931->0:Proceeding
Q931->0:Proceeding
Connect H245...     <============= right here the call connects but there is no audio
H245 TCP conn a0101a4 1740
12:00;0,0,0,0,
12:30;0,0,0,0,
TCP connect err: -33
H245<-0:EndSessionCmd 0
[0:0]Rel LBRC Res
Q931<-*:ReleaseComplete

what appears to be missing from the above is the negotiation of RTP and codecs seen here:

Connect H245...
H245 TCP conn a010197 1740
CESE/MSDSE start:<0 0 0 0>
capSize = 3
Q931->0:Alerting
SCC:ev=10[0:0] 3 0
[0]StartTone 3
H245->0:Cese
[0]: OOB DTMF
RmtAudioCap <4 1>
MD/FRM 1 60
RmtAudioCap <4 3>
RmtAudioCap <4 8>
RmtInputCap <17 1>
RmtInputCap <17 4>
Capability set accepted
H245->0:MSD: <rn tt> = <0x64504f 50>
[0]Master Tx:1 TxRemote:1
H245->0:CeseAck
H245->0:MsdAck
h323.c 2112: cstate : 4
->H245<0> OLC
H245<-0:LcseOpen
TxAud = G711 (1) 20 fpp
G.711 Silence Suppression on
H245->0:LcseOpen
H245->0:OLC mode 1
remote OpenLogicalReq G711/G729(1) : 20 fpp
OpenRtpRxPort(0,0x0,16384):1
RTP Rx Init: 0, 0
RTP->0:<0xa0101a4 16384>
H245->0:LcseOpenAck
RTP<-0:<0xa010197 16384>
[0]Enable encoder 8
[0]: EC 1
Enable LEC adapt [0]=1
RTP TX[0]:SSRC_ID = 7a4b98b4
RTP Tx Init: 0, 0
Q931->0:Connect
Enable LEC adapt [0]=1
[0]StopTone
[0]DPKT 1st: 800 560, pt 8
SCC:ev=12[0:0] 3 0


At first I suspected a codec/negotation parameter mismatch but I configured the two ATA's identically and could place calls between them fine while both where on the same side of ISA. I then moved one to the other side and got the failure mode. I should note that all these tests are in a lab / LAN speed environment so performance or "weather" can't really explain the differences between the ATA:ATA and ATA:Netmeeting tests.