H323 calls

[juan_cye_ccna]

Hi,

I have some problems with calls from internet through h323 ok with SIP, these can not be make. the network topology is below:

SX20 A, SX20 B,SX20 C -> VCS stater pack (dual nic)-> firewall -> internet -> tandberg c60 (not registered in VCS)

in this scenario, from internet can i  make calls to any internal sx20 registered in VCS?

I appreciate your comments.

Thanks in advance.

[ahmashar]

you need to provide much more info than what you provided.

for example what error message do you get? what search rules do you have on VCS for H323? have you open the port on firewall for H323 protocol required communication ports?

for receiving calls from internet, have you configured the SRV record on DNS server?

[juan_cye_ccna]

Ahmad thanks for reading that.

But my question is from internet without any endpoint register to VCS (expressway or starter pack) can i place calls to internal registered endpoints via h323 protocol?

[ahmashar]

sure. The external endpoint will enquire the domain address of internal endpoint from DNS and if DNS was configured with correct SRV record of VCSe server, hence the call will be directed to internal endpoint with correct search rules on VCS.

[juan_cye_ccna]

Hi Ahmad,

SRV records are posted on internet and there is a static NAT on firewall to VCS starter pack, acordingly to my network:

SX20 A, SX20 B,SX20 C -> VCS stater pack (dual nic)-> firewall -> internet -> tandberg c60 (not registered in VCS)

can i place calls to any internal registered endpoints via h323 protocol? for example:

from polycom or tandberg h323 endpoint dial out: user1@mydomain.com (like SIP URI) as this domain and SRV are known on internet DNS.

[ahmashar · Accepted solution]

Hi Juan,

sure you can place a call to any internal endpoint. if your SRV record on public DNS configured correctly something like this:

Query type	Name	TTL	Class	Type	Response

A	cisco.com.	60370	IN	A	72.163.4.161
AAAA	cisco.com.	60330	IN	AAAA	2001:420:1101:1::a
SRV	_h323ls._udp.cisco.com.	3599	IN	SRV	1 0 1719 vcsgw.cisco.com.
SRV	_h323cs._tcp.cisco.com.	3600	IN	SRV	1 0 1720 vcsgw.cisco.com.
SRV	_sips._tcp.cisco.com.	3600	IN	SRV	1 0 5061 vcsgw.cisco.com.
SRV	_sip._tcp.cisco.com.	3095	IN	SRV	1 0 5060 vcsgw.cisco.com.

then when a call like H323:1234@yourdomain.com arrives at VCSE, VCSE looks up through its search rule ( if correctly configured) and forward the call to the registered endpoint (like a pbx).

regards, Ahmad

[juan_cye_ccna]

Hi Ahmad and Jens,

i  appreciate your comments and so sorry to my doubts but i was told me that those kind of calls don't work and the only way to place calls is configuring "Fallback alias" parameter but this is "mapped" to only one internal endpoint alias and is not optimal solution. this means that the h323 alias 1234@mydomain.com (for example) is it same like SIP URI?

[Jens Didriksen]

The purpose of the "Fallback alias" is to allow external end-points which are unable to us Annex O (URI) dialling, to call the public IP address of your VCS-E, which will then be sent to a specific end-point, or, if an MCU is in place, to a MCU auto-attendant or wherever you want it sent.

this means that the h323 alias

1234@mydomain.com

(for example) is it same like SIP URI?

Yes, that is correct, you can in fact use the same address for both H.323 and SIP if you like.

All of our end-points register to our VCS with both H.323 and SIP, with the same address for both protocols.

/jens

[ahmashar]

Fallback alias is for IP address dialing.

[Jens Didriksen]

Yes you can.

Depending on your configuration, they can either call your end-points using Alias@VCS-E_Public_IP_address, or, if you have the relevant SRV records in place, Alias@domain, ie. mysx20@mycompany.com.

For the above to work, the C60 must be running TC4.2 or later, if it's got an earlier version than that, then it can only call IP addresses without being registered to a GK.

Incoming SIP calls will obviously not work without the C60 being registered to a SIP registrar.

/jens

[juan_cye_ccna]

Hi Jens,

I have red that h323 protocol only works to point to point calls and my network has connections as follows:

SX20 A, SX20 B,SX20 C -> VCS stater pack (dual nic)-> firewall -> internet -> tandberg c60 (not registered in VCS)

in firewall was configured a static NAT to only the VCS not to each internal endpoint, taking account this, Does it work if i place a call to any internal SX20?

[Jens Didriksen]

As Ahmed said:

when a call like H323:

1234@yourdomain.com

arrives at VCSE, VCSE looks up through its search rule ( if correctly configured) and forward the call to the registered endpoint (like a pbx).

Using Alias@VCS-E_public_ip_address works the same way, just bypassing DNS, however, you might have to transform this to Alias@Domain for it to work.

Your end-points register to the VCS with their alias, which references their IP address, in this case internal addresses, but this is only so the VCS will know where to send the call. Makes no difference to the external end-point as it is not using, nor calling, the IP address of your end-point. In fact, the only IP address the external system sees, is the public IP address of your VCS-E.

But, as I said, if the external system is a C-series, then these must run TC4.2 or later.

/jens

[Martin Koch]

Jens: did you try dialing  alias@vcsip or e164@vcsip? I would have said it should work with older

versions as well. Its only the SRV support which was added, ....

[Jens Didriksen]

No Martin, this is a well know issue, prior to TC4,2 there was no H323_CS support, so no Annex O type dialling could be done without registering endpoint to a GK.

/jens

[Martin Koch]

If this is one of your endpoints you could also think of registering it to the VCS-E-SP.

Like Jens said, it works with properly set up SRV records when the software version is new enough.

Do you want 4 systems in the same call at the same time? Also no problem if the C60 has

multisite and there is enough bandwidth available.

As its a bit hard to follow withought knowing your deployment (like the exact topology,

network, call flow, other demands ...) I would strongly suggest you to talk to a Cisco partner

or an external consultant to find the best solution for you.

Such issues are way easier fixed by a short disucssion rather than a forum back and forth which

then at the end might fix one issue, but did not address the core issue :-)