FXS Calls fail on VoIP over IPSec over ADSL

Unanswered Question
Jun 28th, 2007

I have installed a long time ago two 1750 routers and one 2610, that had serial connections. Then, my costumer started evolving his network and wanted to put up VoIP. At the time, the available IOS was 12.0(7)T and the config was based on multilink interfaces.

Meanwhile, the same costumer became interested in V3PN, but realized that the existing routers, though old and now unsupported, fitted his purposes with VoIP over IPSec over ADSL. After recommending the routers replacement and being ignored, I started the tortuous process of implementing a WIC-1ADSL on the 1750 routers and implementing IPSec. The tunnels are up and running and the data packets flow without problems. As anyone can imagine, it was a headache to find an appropriate IOS - 12.2(8)TPC10b - the latest one available to the 1750 routers.

After the implementation of IPSec and data flow, I removed the serial interfaces and it was time to put the voice up to work with the IPSec tunnels, because it was already working with the serial interface before, which was merely (I thought, after being surprised the ADSL an IPSec worked fine) a question of sending voice packets over the IPSec, with the best QoS possible.

From the way from the 2610 router to the 1750 routers, I can establish a h.323 voice session and talk normally. From the 1750 #1 to the 1750 #2 and from these to the 2610, I can't even connect a session, it fails, I believe on the Hook Up event, or at least on the number dial. The 2610 has an ASA5510 making the Internet border, but the data flow is ok, and the ACLs that define the encrypted traffic are working nicelly.

I really can't see what the problem is.

TIA.

Cheers,

Nelson Neves

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Anonymous (not verified) Thu, 06/28/2007 - 12:43

I'll try to post up the configs and the debugs I made, but the server keeps returning me servlet errors, can't promisse I can make this.

Cheers,

Nelson Neves

Paolo Bevilacqua Thu, 06/28/2007 - 14:07

Hi, excuse the basic question, do you have connectivity between the 1750's, check via ping to the h323 bind interface, source from the h323 bind interface.

Anonymous (not verified) Fri, 06/29/2007 - 02:22

Hi, yes, I have connectivity between all the involved IP Addresses. The data packets flow nicely over the IPSec. The voice calls never come out of the router.

The logic diagram (ascii) is like this:

-2610

192.168.10.254 - eth0

192.168.254.254 - lo0

3.. - dial-peer

- 1750 #1

192.168.30.254 - eth0

192.168.254.252 - lo0

4.. - dial-peer

- 1750 #2

192.168.20.254 - eth0

192.168.254.253 - lo0

5.. - dial-peer

2610 --- AS5510 --- Internet --- 1750 #1 and #2

Cheers,

Nelson Neves

Anonymous (not verified) Fri, 06/29/2007 - 02:31

Below is one of the debugs I made from a call being csimed from router 1750 #2 to 2610.

Debug VOIP CCAPI INOUT (1750 #2 to 2610) - doesn't work

-----------------------------------------

RP1#csim start 309

csim err:csim_do_test invalid major major(16) minor(0)

RP1#

1d02h: csim: called number = 309, loop count = 1 ping count = 0

1d02h: ccAppInitialize (name=CSIM , appHandle=0x82136680)

1d02h: csimSetupPeer peer type(2), destPat(309), matched(1), target()

1d02h: ccCallSetupRequest (Inbound call = 0xFFFFFFFF, outbound peer =3, dest=, params=0x82135BF0 mode=0, *callID=0x82136020, prog_ind = 0) callingIE_present 0

1d02h: ccCallSetupRequest numbering_type 0x0

1d02h: ccCallSetupRequest encapType 2 clid_restrict_disable 1 null_orig_clg 0 clid_transparent 0 callingNumber

1d02h: dest pattern 3.., called 309, digit_strip 0

1d02h: callingNumber=, calledNumber=309, redirectNumber= display_info= calling_oct3a=0

1d02h: accountNumber=, finalDestFlag=0,

guid=0000.0000.0000.0000.0000.0000.0000.0000

1d02h: peer_tag=3

1d02h: ccIFCallSetupRequestPrivate: (vdbPtr=0x81DC862C, dest=, callParams={called=309,called_oct3=0x0, calling=,calling_oct3=0x0, calling_xlated=false, subscriber_type_str=, fdest=0, voice_peer_tag=3},mode=0x0) vdbPtr type = 1

1d02h: ccIFCallSetupRequestPrivate: (vdbPtr=0x81DC862C, dest=, callParams={called=309, called_oct3 0x0, calling=,calling_oct3 0x0, calling_xlated=false, fdest=0, voice_peer_tag=3}, mode=0x0, xltrc=-5)

1d02h: cc_insert_call_entry: not incoming entry

1d02h: cc_insert_call_entry: entry's incoming FALSE. is_incoming is FALSE

1d02h: ccCallSetContext (callID=0x14, context=0x81D67704)

1d02h: cc_api_supported_data data_mode=0x10002

1d02h: cc_incr_if_call_volume: remote IP is 192.168.254.254

1d02h: cc_incr_if_call_volume: hwidb is Dialer1

1d02h: cc_incr_if_call_volume: create entry in list: 1

1d02h: csim: loop = 1, failed = 0

1d02h: csim: call attempted = 1, setup failed = 0, tone failed = 0

1d02h: ccCallDisconnect (callID=0x14, cause=0x2F tag=0x0)

1d02h: cc_api_get_transfer_info: (callID=0x14)

1d02h: cc_api_icpif: expect factor = 0

1d02h: cc_decr_if_call_volume: the remote IP is 192.168.254.254

1d02h: cc_decr_if_call_volume: hwidb is Dialer1

1d02h: cc_decr_if_call_volume: reduce callnum of entry: 0, voip: 0, mmoip: 0

1d02h: cc_decr_if_call_volume: remove an entry

1d02h: cc_api_call_disconnect_done(vdbPtr=0x81DC862C, callID=0x14, disp=0, tag=0x0)

1d02h: cc_delete_call_entry: not incoming entry

1d02h: cc_delete_call_entry: entry's incoming FALSE. is_incoming is FALSE

Cheers,

Nelson Neves

Paolo Bevilacqua Fri, 06/29/2007 - 03:31

Hello,

not to insist, but I'm afraid the call can start with the wrong source address.

Do you have h323 bind statements to the loopback interfaces ?

Anonymous (not verified) Mon, 07/02/2007 - 01:45

Hi,

No problem about insisting :) I really am startled with this situation, so any sugestion is a good one. Nonetheless, I'm affraid that posting an attach in the forum returns errors to me, so I'll post the necessary.

Here's the main loopback configuration:

interface Loopback0

ip address 192.168.254.253 255.255.255.255

h323-gateway voip interface

h323-gateway voip bind srcaddr 192.168.254.253

The configuration is the same on 1750 #1 and #2. The 2610 IOS doesn't have the necessary commands, so the connection always comes from the ethernet interface.

Cheers,

Nelson Neves

Paolo Bevilacqua Mon, 07/02/2007 - 07:58

This is surprising. The 2610 is probably starting the call with the wrong interface and succeeds, while the ones that do have loopback binded to H.323 can't.

Anyway, do you have the looback interfaces / 2610 in the access-list applied to the crypto map, and viceversa at the hub ? Or perhaps you have an IPsec tunnel straight betwwen spokes.

If no real need for encryption, would you consider running this over GRE tunnels instead for a smaller overhead and easier life ?

Actions

This Discussion