Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

CME conferencing source IP address

I have a customer who is implementing CME with conferencing. They have remote sites across a QoS-guaranteed WAN and are running IPSec VPN between the sites. When they create conference calls, the source IP address of the audio stream going to the remote site is the public interface of the CME router. This creates one-way audio where the remote phone cannot hear the bridge because the audio traffic is not being put into the VPN tunnel. We need to be able to specify that the audio traffic always originate from the private interface IP address.

We have the "ip source-address" command specified under "telephony-service" and also tried the "h323-gateway voip bind srcaddr" and "h323-gateway voip interface" commands under the private interface but those did not work either.

Any ideas how we can force the CME conference bridge to always use the private interface IP address as conference source? Thanks!

3 REPLIES
Silver

Re: CME conferencing source IP address

Generally you cannot encrypt packets on the same router that generates the packets. Packets need to go through the router. There are 2 workarounds:

1. Run a GRE tunnel inside the IPSec tunnel, since the GRE packets essentially get routed over the VPN tunnel the router will encrypt them.

2. Policy route packets through a loopback

a. Create a loopback interface with an ip address

b. 'ip policy route-map FORCE-TUNNEL'

c. create the policy route-map to set the next hop of the other end of the vpn tunnel

d. add a static route for the other h323 or callmanager endpoint pointing to the loopback you created in step (a)

Pertinent config:

dial-peer voice 7000 voip

destination-pattern 7000

session target ipv4:172.31.0.10

codec g729br8

ip route 172.31.0.10 255.255.255.255 loopback1 5

interface loopback1

ip address 10.255.255.1 255.255.255.252

ip policy route-map FORCE-TUNNEL

ip access-list extended FORCE-TUNNEL

permit ip any host 172.31.0.10

route-map FORCE-TUNNEL permit

match ip address FORCE-TUNNEL

set ip next-hop 10.255.0.2 <-- ip of vpn tunnel next hop

As always, ask additional questions and rate this post if it helped you.

New Member

Re: CME conferencing source IP address

I thought this only applies to ACLs, i.e. the router does not apply outbound ACLs to traffic generated internally. I can do extended pings and run SAA traffic through a VPN tunnel that originates from within the same router. Does this not apply to voice traffic for some reason?

Silver

Re: CME conferencing source IP address

Packets originated by the router processes will not be encrypted when you use crypto maps. That is why the crypto map functionality has been replaced by the virtual tunnel. In most cases with Symphony, packets will not be encrypted using a crypto map because the router only processes crypto maps as packets cross the router. This can be fixed by using a GRE tunnel within the the IPSec tunnel (because the packets are now processed a second time as GRE packets), by routing via a policy-routed loopback (as the packet is routed a second time), or by using a virtual tunnel which provides the same functionality of a GRE tunnel within an IPSec tunnel, without the GRE part. This works because the design of a virtual tunnel interface is to route packets into the tunnel and then route the encrypted packets. The virtual tunnel interface was created in part to resolve the issue you describe. (Symphony is the voip functionality within an IOS router, CME leverages most of this functionality that has been available for 10 years).

See the following URL for more info:

http://www.ciscotaccc.com/kaidara-advisor/voice/showcase?case=K21063671

200
Views
0
Helpful
3
Replies
CreatePlease to create content