Dead air on E1 <-> Call Manager

[alistair.cunningham]

I'm setting up a call manager network as follows:

Call Manager 3.1(3a) on IP address 10.1.3.2

Some 7940 and 7960 handsets

A 1760-V (version 12.2(8)YJ) on IP address 10.1.1.5

Slot 0 has an E1 (2 port) Multi-Flex Trunk WAN daughter card

Slot 2 has a dual NT or TE BRI Voice Interface Card

A 2950G-48-EI switch to connect them all

The telephones can all call each other correctly, and with good voice quality.

The 1760 can ping everything (subject to the normal packet loss when pinging phones), so I don't think routing is a problem.

When a test call is placed from an E1 PRI-ISDN tester attached to port 0 on the dual E1 card, with calling number being 912345, and called number being 121004 (one of the 7940 handsets), the handset rings, and displays the correct calling number. However, when the handset is picked up both ends hear only silence.

The phone can play DTMF to the tester, and the tester plays the appropriate tones out of it's speaker, but DTMF doesn't seem to be being sent from the tester to the phone.

On running an ethernet sniffer, I can see that the 1760 is communicating with the call manager as I would expect. The phone is sending many G.711 ulaw RTP (even though the 1760 is set as an H.323 gateway in the call manager route pattern) packets to the 1760 (shouldn't these be alaw?), but the only packets being sent from the 1760 to the phone are a very few RTCP packets. I also see that DTMF from the phone the the 1760 is going via skinny to the call manager, which explains the behaviour above.

The config of the 1760 is available at:

http://217.206.195.242/maori.txt

This raises the following questions:

- Shouldn't the phone be sending H.323 packets rather than RTP?

- Shouldn't it be using alaw rather than ulaw?

- Why is the 1760 not sending any voice packets to the phone?

- Are any of the above causing the dead air in both directions, or is it something else?

If anyone would like further clarification of the config, I'd be delighted to post it here.

Alistair Cunningham

[marinaibm]

Hi Alistair..

Try to add on the 1760

ip route 0.0.0.0 0.0.0.0 10.1.1.1

Well, probably someone else can give you better answers but my opinion is like that:

1.h323 is only signaling, RTP stream will be sent in any case

2.ip phones are using ulaw by default but they will negotiate it with alaw call

3.To my knowledge 1760 isn't sending pckets because it's confused what interface it should send it thru , thats why i asked you to add ip route command.

4.The previous problem causes the dead air(hopefully)

Another question is if your default gateway (10.1.1.1) is placed on the same switch as well?

marina

[alistair.cunningham]

Thanks for the response on points 1 and 2.

On point 3, I've added the route as you say, but it doesn't seem to to have changed anything. Packets are still being sent from phone to 1760, but not from 1760 to phone. Both ends still hear dead air.

The default gateway is on the same switch.

[marinaibm]

Sorry for a stupid question, but could you explain again the way your tester behaves?Is it sending out only dtmfs?

you would like to add

dtmf-relay h245-alphanumeric

to your voip dial-peer to allow dtmf transmition

[alistair.cunningham]

Oh, there are no stupid questions!

The tester can send both voice and DTMF, like a normal phone.

Now that packets are passing both ways, and I've added the dtmf-relay, I can see that when I press a DTMF key on the tester, an H.245 message is sent from the 1760 to the call manager, and a skinny message from the call manager to the phone. The phone plays no sound, but I guess this is normal for 7960 phones; no sound is played when calls are made from phone to phone. Thus DTMF seems to be now working correctly in both directions. Thanks for your help!

Only the voice is now missing; anyone any ideas?

[marinaibm]

Regarding the missing voice, can you try

call rsvp-sync

in the global config

[marinaibm]

ignore this one, you have already got it...sorry

[alistair.cunningham]

It was already set, but doesn't seem to be being used:

maori#show call rsvp-sync stats

VoIP QoS: Statistics Information:

Number of calls for which QoS was initiated : 0

Number of calls for which QoS was torn down : 0

Number of calls for which Reservation Success was notified : 0

Total Number of PATH Errors encountered : 0

Total Number of RESV Errors encountered : 0

Total Number of Reservation Timeouts encountered : 0

[marinaibm]

can you capture

debug voip ccapi inout

for one call

[alistair.cunningham]

If I do an 'ip routing', then add the route, I can see that the 1760 is now sending packets to the phone, and the phone to the 1760, so that part is now resolved!

Alas, both ends still hear silence. I notice that the packets being sent both ways are still ulaw. Will ulaw VoIP work with E1? Is there still some other problem?

[alistair.cunningham]

By the way, you wouldn't happen to be the Marina who was working on the Call Manager project in IBM Azorim last year? If so, we've met - I was the engineer who installed the Message Center system.

[marinaibm]

i know, thats why i'm trying to help so hard :)