Video end point issue

kpmgnz · ‎07-14-2009

We are trying to get our 3845 to handle video calls.

We meet the Cisco prerequisites.

Downgrading the Polycom speed to 2x64 and it works, when bumping the speed up to 256/384 it wont establish the connection.

Do we need to create ISDN pools or something along those lines to improve the quality?

Related config

voice class codec 10

codec preference 1 g722-48

codec preference 2 g711alaw

video codec h261

video codec h263

video codec h264

interface Serial0/0/1:15

isdn integrate calltype all

dial-peer voice 3463 voip

destination-pattern 5463

voice-class codec 10

session target ipv4:10.155.0.001

!

dial-peer voice 34631 pots

information-type video

incoming called-number 3463

direct-inward-dial

Any help would be appreciated

pcameron · ‎07-17-2009

We got this working in the lab for inwards and outwards video calling. Attached are the configs that may help.

The ISDN D channel needs the command 'isdn integrate calltype all' to allow the data/video bearer cap to be handled. You also need a 'voice class codec' that includes video codecs, and a 'voice class called number inbound/outbound' command that has the individual numbers used for the video calls.

The feature is described here -

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/h320gw.html

The attached configs were for a back to back ISDN connection between the two routers. One router (2821) was runing as a H323 gatekeeper that all the H323 devices were registered to. The video calls were done using the Polycom PVX application (demo copy downloaded from here - http://www.polycom.com/apac/en/support/video/pvx.html). The other router was emulating the PSTN and also had the Polycom PVX application working through it. The calls worked fine at 384K.

shoaib.usmani · ‎07-29-2009

Hello,

The information is really helpful. Could you please explain how the "voice class called number inbound/outbound" works? Do the range of the numbers have to be in valid DDIs? I looked at the attached document but couldn't work out how these numbers are allocated.

Many thanks,

Shoaib.

Nicholas Matthews · ‎07-29-2009

If you have problems with higher speeds, it could also be caused by media negotiation timers.

Quite frequently when there is a CUCM involved, speeds about 64/128 will not consistently connect.

It is suggested to go into the service parameters and change the Media Exchange Timer and H245 Timeout timers to 30 seconds. As well, if these values, or their equivalent, are available on the endpoints interacting with the gateway it is suggested to change them to 30 seconds.

When you do H320 video, the H245 media negotiation does not happen until the last channel has sync'd up, which is quite a bit later than when you do 64 kpbs.

As well, by default all dial peers allow all video codecs through by default. By specifying a video class codec you are only filtering out possibilities. You should be able to get this to work without adding video codecs to your dial peers.

hth,

nick

kpmgnz · ‎08-05-2009

We have been able to get this to work now, video quality is fine, however the audio is stuck at 56k and sounds like a robot, only in one direction?

The problem we faced was we had calling translations for a extention range, we used the translated number as the 'incoming called number' instead of the original extention.

So we were entering 5XXX instead of 3XXX

voice class called number pool 100

index 1 3463

voice-port 0/1/0:15

voice-class called-number-pool 100

dial-peer voice 3463 voip

destination-pattern 3463

voice-class codec 10

session target ipv4:10.155.0.999

!

dial-peer voice 34631 pots

information-type video

incoming called-number 3463

bandwidth maximum 384

direct-inward-dial

Anyone had any issues getting audio to run @ 64k?