© 2008 cisco systems, inc. all rights reserved.course acronym vx.x—#-1 h.320 ios gateway

© 2008 Cisco Systems, Inc. All rights reserved. Course acronym vx.x—#-1

H.320 IOS Gateway


Agenda

H.320 Protocol Overview

H.320 IOS gateway feature

H.320 gateway configuration

H.320 troubleshooting


H.320 Protocol Overview


The H.320 suite addresses videoconferencing over circuit switched services like ISDN.

Specifies requirements for processing audio and video information.

Provides common formats for compatible audio/video inputs and outputs, and protocols that allow a multimedia terminal to utilize the communications links and synchronization of audio and video signals.

The H.320 suite consists of several ITU specifications, including H.320/H.221/H.242/H.230/H.241.

H.320 Description


H.320 Generic Diagram

H320 System diagram


H.320 System control signal flow

The path for the terminal-to-network control is through ISDN D-channel (Q931).– One H320 call may consist of multiple ISDN calls: one

primary call and zero/one/multiple secondary calls.– Regular ISDN call setup/teardown procedure.– Bearer-cap set to unrestricted digital.

The path for terminal-to-terminal control is through BAS channel defined in ITU H.221


H.221 Overview

Defines frame structure for audiovisual tele-services in single or multiple B or H0 channels or a single H11 or H12 channel

Subdivides an overall transmission channel of 64 to 1920Kbps into lower rates suitable for audio, video and data purpose.

Provides synchronizing and ordering transmissions over multiple B channels.


Bit Allocation Example for 2B (2x64) Call


Ipanema H.320 GW

Recognize the H.320 call based on dialpeer config.

Bundle multiple ISDN calls into one logical H.320 call and present single call to H323 or SCCP side.

Support in-session control via the conversion of BAS/H245 and BAS/SCCP.


Protocol Interworking Between H.320 and H.323

Component H.323 H.320

Call Control H.225.0 Q.931

System Control H.245 H.242/H.221

Multiplex H.225.0 H.221

Audio G.711, etc G.711, etc

Video H.261, etc H.261, etc

Data T.120 T.120


H.221/H.245 Mapping Examples

H221 command H.245 equivalent

A-law, 0F Open logical channel with AudioCapability of

g711Alaw64K

H.261_on Open logical channel with VideoCapability of H261

VideoCapability

CapMark <caps> CapMark TerminalCapabilitySet

Fast-update (0x51) MiscCommand VideoFastUpdate


H.221/SCCP Mapping Examples

H221 SCCP Message

H.263_on OpenMultimediaReceiveChannel

Fast-update (0x51) StationMiscellaneousCommandMessage/VideoFastUpdate


H.320 Feature in IOS Gateways


Integrated Voice and Video GW in ISR

Video gateway capabilities built into ISR ISDN voice interfacesAllows for extension of currently deployed systems Provides simplified architecture for next generation combined voice and video networksFunctionality Px64 implementation for up to 1024Kbps calls Interoperable with major 3rd party components up to 128K Video Codecs: H261, H263, H.263+, H.264 Protocols: H323

PSTN

ACallManager

ClusterWAN

H.320H.320

H.320H.320 H.320 Voice/Video

IP Voice/Video


H.320 General Feature Description Provides for calls between H.323/SCCP to H.320. Each H.320 call can be from 1B (64k) up to 16B (1024K), using bandwidth

configuration.– 1024K max in back to back gateway configuration– 128k max in H.320 video terminal to gateway configuration (H.320

terminals only support 128k in H.221 mode) in 12.4(11)T release. The 12.4(20)T release allows ISO 13871 channel bonding to allow higher bandwidths.

Support for the feature is on the c5510 TI DSPs. Each DSP can support 16B worth of H.320 calls, and can be mixed with other call types (voice/fax/modem).

Supported voice codecs:

– G.711 (64, 56, and 48kbps)– G.722 (64, 56, and 48kbps)– G.728 – G.729

Supported Video codecs:

– H.261, H.263, H.263+, H.264


H.320 General Feature DescriptionH.320 specification Translate H.221 frames into RTP audio / video packets Translate RTP audio / video packets into H.221 frames

H.221 Encapsulation on H.320 side Dynamic adding and removing of B-channels during call setup Automatic frame and multiframe alignment and channel synchronization BAS signaling processing with squelching

Dynamic secondary call number exchange using ITU H.242

RTP encapsulation on H.323/SCCP RFC 3550 (G.711, G.722 (64, 56, and 48kbps), G.728, G.729) RFC 2032 (H.261 Video) RFC 2190 (H.263 Video) RCF 2429 (H.263+ Video) ITU-T H.241 Annex-A (H.264 Video)


Dial-peer configuration for audio/video codec:

Default codec for H.320 calls – The default audio/video codec on the dial-peer for H.320 calls is codec transparent. This gives the endpoints to control the desired audio/video codec selection based on the bandwidth of the call. Endpoints would prefer H.264 codec for calls at 128Kbps and H.263 for higher bandwidths.

What is codec transparent – Gateway would pass the list of codecs coming from H.320 remote endpoint across to the H.323 remote endpoint and vice-versa. But only the codecs that are supported by the gateway are passed.

Audio/Video codec filtering – To give the user control over desired audio/video codec selection and for inter-operability the audio/video codecs can be configured on the dial-peer. This will only forward the codecs that are configured on the dial-peer if advertised by the remote endpoints.


Numbering Descriptions: Static vs. Dynamic

Normally, an H.320 terminal would have one or more numbers assigned, just like a normal POTS line. In this feature, the IOS gateway is becoming a virtual H.320 terminal on one side of the H.320 call. This facilitates the need to have numbers ‘assigned’ to the IOS gateway.

The IOS gateway gets around this by allowing the user to configure number pools for H.320 calls. These pools can work in 2 modes, static or dynamic.

Static numbering is used when both sides of the H.320 call know what all of the secondary leg numbers will be. Numbers may be repeated, but both sides know the numbers. No numbers are passed between the terminals.

Dynamic numbering is used when only the called H.320 terminal (or IOS gateway) knows the secondary leg numbers (the primary call leg number is known). Once the H.320 primary call leg is established, the called H.320 terminal will pass the secondary leg numbers to the calling H.320 terminal, using ITU H.221/H.242 standards or ISO-13871 bonding. Currently the IOS gateway will support only the ITU H.221/H.242 method.


H.320 Feature Limitations Only TI c5510 DSP supported. No other DSP type is supported. The DSP must have enough available timeslots for the H.320 call (the call

cannot span DSPs). Feature supports G.729 audio, but no G.729 support for SCCPH.320

directly. (If the same router is the CME, and the H.320 gateway, the phone should be configured for G.711)

G.722 is supported for H.320, but not for general TDM calls. No G.722 32k and 24k audio. No RFC3984 support for H.264. TDM interface must be ISDN (BRI or PRI). No other TDM interface types

are supported (i.e. E1 MFCR2). The member interfaces of trunk-group or NFAS group must reside on

c5510-based NMs and/or 28/38 onboard slot. No DTMF support (that is, no inband to out of band conversion). No Overlap dialing. No Supplementary services.


H.320 IOS Supported Platforms and ModulesPlatforms

2600XM 2691 3700 2800 3800

Hardware Modules

NM-HD

NM-HD-2V

NM-HD-2VE

NM-HDV2

VWIC-xMFT-x

VIC2-2BRI

VIC-(EVM-BRI)

VWIC2-xMFT-x


Gateway Configuration


H320 Video Network Setup: Tested Components

CME/SRST 4.0 CCM version 4.1 & 4.2 CVTA version 1.0(2) CUVA version 2.0(1) Skinny Endpoints

– Cisco IP-Phones: (phone supported are 7940, 7941, 7960, 7961,and 7970)

– 7940/7960 with firmware: P00306000500 and P00307020300– 7941/7961 with firmware: TERM41.7-0-1-43DEV– 7970 with firmware: TERM70.6-0-2-0s and TERM70.7-0-1-0s – Tandberg version: E3.0 and E4.1

H323 & H320 Endpoints Tandberg version: E3.0 and E4.1 Polycom version: Release 7.5.2


Call Flows

Call Flows for H.320 (to/from PSTN): H.320 to/from SCCP Audio/Video Endpoints H.320 to/from H.323 Audio/Video Endpoints CCM(H.323 trunk) to/from H320 Endpoints

Call Flows in SRST Mode Local SCCP Audio/Video H320 SCCP Audio/Video Local SCCP Audio/Video H.320 Audio/Video


TDM Configuration

Controller t1 1/0

pri-group timeslots 1-24

interface Serial1/0:23

no ip address

isdn switch-type primary-ni

isdn integrate calltype all


secondary number configuration: Static

Outgoing H320 calls: voice class called number outbound 100

– index 1 6502221100 - 6502221111 dial-peer voice 3000 pots

– voice-class called-number outbound 100

Incoming H.320 calls: voice class called number inbound 100

– index 1 65022211.. dial-peer voice 4000 pots

– voice-class called-number inbound 100


secondary number configuration: Dynamic

Incoming H.320 calls:

voice class called number pool 100

index 1 6502221111 - 6502221116

voice-port 1/0:23

voice-class called-number-pool 100


Pots Dial-peer configuration (Static)Outgoing H.320 calls dial-peer voice 124 pots

– information-type video

– destination-pattern 6505552222

– bandwidth maximum 384

– voice-class called-number outbound 100

– port 4/1:23

Incoming H.320 calls: dial-peer voice 123 pots


– incoming called-number 6505552222

– bandwidth maximum 384 minimum 384

– voice-class called-number inbound 100

– direct-inward-dial


Pots Dial-peer configuration (Dynamic)Outgoing H.320 calls: dial-peer voice 124 pots


– destination-pattern 6505552222

– bandwidth maximum 384

– port 4/1:23

Incoming H.320 calls: dial-peer voice 123 pots


– incoming called-number 6505552222

– bandwidth maximum 384 minimum 384

– direct-inward-dial

Voice-port 1/0:23

– voice-class called-number-pool 100


H323 configuration

voice service voip

h323

call start slow


Voip Dial-peer configuration

voice class codec 100

codec preference 1 [G.711, G.722 (64, 56, and 48kbps), G.728, G.729]

video codec [h261/h263/h263+/h264]

dial-peer voice 7001 voip

video codec [h261/h263/h263+/h264]

codec [G.711, G.722 (64, 56, and 48kbps), G.728, G.729]

rtp payload-type cisco-codec-video-h263+ [96-127]

rtp payload-type cisco-codec-video-h264 [96-127]


H.320 Gateway

H.320Call Leg

H.320Call Leg

H.323Call Leg

H.323Call Leg

Config Example -default

dial-peer voice 919 voip

destination-pattern 919....

H.320-EPCodecs:

g711ulaw, g722-64,g728, h261, h263

H.320-EPCodecs:

g711ulaw, g722-64,g728, h261, h263

H.323-EPCodecs:

g711ulaw, g722-64,g722-48, h261 h263+, h264

H.323-EPCodecs:

g711ulaw, g722-64,g722-48, h261 h263+, h264

g711ulaw, g722-64, g728

h261, h263

g711ulaw, g722-64, g722-48

h261, h263+, h264


g711ulaw, g722-64, g728

h261, h263

g711ulaw, g722-64, g722-48

h261, h263+, h264


H.320 Gateway

H.320Call Leg

H.320Call Leg

H.323Call Leg

H.323Call Leg

H.320-EPCodecs:

g711ulaw, g722-64,g728, h261, h263

H.320-EPCodecs:

g711ulaw, g722-64,g728, h261, h263

H.323-EPCodecs:

g711ulaw, g722-64,g722-48, h261 h263+, h264

H.323-EPCodecs:

g711ulaw, g722-64,g722-48, h261 h263+, h264

g711ulaw, g722-64, g722-48

h261, h263+, h264

Config Example – codec filter

dial-peer voice 919 voipdestination-pattern 919….codec g711ulawvideo codec h263


g711ulaw, g722-64, g728

h261, h263

g711ulaw, h263

g711ulaw, h263


Dynamic (H.242) Secondary Dial PlanConfiguration

interface Serial4/1:23 isdn integrate calltype all

dial-peer voice 124 pots information-type video destination-pattern 6505552222 bandwidth maximum 384 port 4/1:23

H320

OGW TGW

voice class called number pool 100 index 1 6502221111 index 2 6502221212 index 3 6503332222–6503334444

interface Serial3/1:23

isdn integrate calltype all

voice-port 3/1:23 voice-class called number pool 100

dial-peer voice 123 pots information-type video incoming called-number 6505552222 bandwidth maximum 384

6505552222


Dynamic (H.242) Secondary Dial PlanCall Setup Flow

H320OGW TGW

6505552222

Sec call setup: 6502221212 (Q.931 setup)

Secondary number exchange: 6502221111, 1212, 2222, 2223 (H.221/H.242 messages)




Primary call setup: 6505552222 (Q.931 setup)


Static Secondary Dial PlanConfiguration

voice class called number outbound 100

index 1 6502221111 index 2 6502221112 index 2 6502221113 index 3 6502221114 index 4 6502221115 index 5 6502221116

interface Serial3/1:23 isdn integrate calltype all

dial-peer voice 124 pots information-type video destination-pattern 6505552222 bandwidth maximum 384 voice-class called-number outbound 100 port 4/1:23

H320

OGW TGW

voice class called number inbound 101

index 1 650222111.interface Serial4/1:23 isdn integrate calltype all

dial-peer voice 123 pots information-type video incoming called-number 6505552222 bandwidth maximum 384 minimum 384 voice-class called-number inbound 101

65055522226505551111


Static Secondary Dial PlanCall Setup Flow

H320OGW TGW

6505552222

Sec call setup: 6502221112




Primary call setup: 6505552222


Troubleshooting


Show Commands

Show ephone registered

Show call active video [compact/brief]

Show call history video

Show voice dsp

Show isdn status

Show voice call summary

Show voice class called-number inbound <tag>

Show voice class called-number outbound <tag>

Show voice class called-number-pool <tag> (Dynamic)


General Debugs for H.320 calls

Debug voip ccapi default Debug cch323 video Debug voip vtsp all Debug voip dsm all Debug voip dsmp all Debug voip h221 all

– Debug voip h221 raw (not activated by all option)– Debug voip h221 raw decode (not activated by all option)

Debug H225 asn1/event/q931 Debug H225 q931 Debug H245 asn1/event Debug ephone video ( debug ephone detail ) Debug dsp-resource-manager flex all Debug isdn q931


New H.221 Debugs

Debug voice/voip h221

This is the new debug class for the H.221 library code. All debugs in the class fully support call filter match-lists.

ALL - Activates error (all), inout, and function only. DEFAULT – Activates error (no informational), inout, and function. ERROR – Activates call error and software error debugs (no informational). ERROR CALL – Activates major call related error debugs. ERROR CALL INFORMATIONAL – Activates major and minor call related error debugs. ERROR SOFTWARE – Activates major software related error debugs. ERROR SOFTWARE INFORMATIONAL – Activates major and minor software related

error debugs.


New H.221 Debugs continued

Debug voice/voip h221 FUNCTION – Activates debugs at the entry and exit points of a code procedure. No

internal data is displayed, only the procedure names. INOUT - Activates in-out debugs. INDIVIDUAL – Activates a single debug using an index number. The list of index

numbers are located in the backup slides. RAW – Displays the raw H221 BAS messages buffers coming to and from the DSP. It

will also display any buffer fragments (pieces of messages requiring the next 25 byte buffer from the DSP), and complete MBE (multi-byte extension) buffers. All messages are displayed in hex.

RAW DECODE – Displays the raw H221 BAS messages to and from the DSP in decoded format. Not every H221 BAS is decoded, only the ones that the router will use. If the router does not use the BAS code, the display will be blank. Please note that the raw decode option does not activate the raw option also. This debug output is very verbose.


Troubleshooting guide

Symptom Troubleshooting guide to reference

H.320 call will not establish • Primary call setup

• Secondary call setup

No audio • Capability exchange

• Cannot establish audio or audio is not heard

No video • Capability exchange

• Cannot establish video

• Video is established, but cannot be seen

Poor video quality • Poor video quality


Troubleshooting: Primary Call Setup

Normally, if the primary call is having problems being established, the problem is usually dial-peer/configuration related.

Things to check Make sure that pots dial-peer has information-type video. Make sure that pots dial-peer that is being used is actually the correct one. Make sure “isdn integrate calltype all” is defined from the supported ISDN interface Make sure that for incoming H.320 calls, the bearer capability is correct (should be 64K

unrestricted digital, 56k digital is not supported)


Troubleshooting: Primary Call Setup

Debugs Debug isdn q931

Debug h225 event/q931 (if IP leg H.323)

Debug voip tsp dialpeer

Debug voip dialpeer inout

Debug voip ccapi inout


Troubleshooting: Secondary Call(s) Setup

The problem of the secondary calls not be established can be more complicated than the primary not being established.

Two major methods of establishing secondary legs exist.

ITU-H.221/H.242 only (pX64 mode, supported)

ISO-13871/ITU-H.244 bonding (p*64 mode, supported in 12.4(20)T code)

For troubleshooting, we will take a look at 3 different cases.

When back to back IOS gateways are connected together via an H.320 link.

When the IOS gateway is connected directly to an H.320 device (directly or via a PBX/switch configuration)

The bandwidth reported via H.221 doesn’t match the range configured on the gateway.


Troubleshooting: Secondary Call(s) Setup; back to back IOS gateway

The IOS gateways can have a secondary number configuration of static numbers, or dynamic numbers.

For the static numbers configuration, both gateways need to know the numbers that will dialed on the secondary legs. No number exchange is passed.

In the dynamic numbers case, the called gateway will send the calling gateway the secondary leg numbers to dial, using the H.221/H.242 protocol. This is done after the primary leg is up, and H.221 frame sync has been achieved.


Troubleshooting: Secondary Call(s) Setup; back to back, static number configuration

For static number calls to work, both routers must have knowledge of all the numbers to dial. The feature was done in a manner that each H.320 doesn’t necessarily need a complete set of numbers. If the calling router doesn’t have enough numbers configured, it will repeat the last number in the configuration enough times to complete all of the calls.

The important thing to remember is that both routers will know about all of the numbers that will be dialed.


Troubleshooting: Secondary Call(s) Setup; back to back, static number configuration

Things to check: Make sure the calling number is the same for each call leg. On the originating router, make sure that the outgoing pots dial-peer has the

correct voice class called number outbound index, and that index has the correct numbers.

On the terminating router, make sure that the incoming pots dial-peer has the correct voice class called number inbound index, and that index has the correct numbers.

Debugs

Debug isdn q931



Troubleshooting: Secondary Call(s) Setup; back to back, dynamic number configuration

For dynamic numbers, the numbers will be passed from the terminating router, back to the originating router. In this case, no configuration is needed on the originating router.

Things to check: That there is a properly configured voice class called number pool index. The voice-port of the incoming ISDN interface should have the correct voice-class

called-number pool. The numbers in the pool should be numbers that will actually route though the

PSTN network between the routers. Remember that translation rules may apply to these numbers also.

Debugs:


Debug isdn q931

Debug voip h221 individual 32 (displays secondary number exchange on the H221 BAS stream)


Troubleshooting: Secondary Call(s) Setup; gateway to H.320 terminal

H.320 terminals typically support either pX64 and p*64 mode.

For most terminals, they will only support up to 2 b-channels in pX64 mode (ITU-H.221 only), and 6 b-channels in p*64 mode (ISO-13871 bonding/ITU-H.221).

This is regardless of how the terminal can be configured (for example, some Polycom H.320 terminals have a 7X64 and 14X64 setting, but will not actually perform this mode).

Also, H.320 terminals typically don’t support the H.242 method of dynamic exchange of numbers for secondary call legs.


Troubleshooting: Secondary Calls(s) Setup; Peer bandwidth doesn’t match gateway configuration

If the advertised bandwidth from the H.320 peer doesn’t fall with the range of the configured bandwidth on the gateway, the call will fallback to a 1B (64K call). This is usually a very easy problem to find.

Things to check:

That the configuration between the two H.320 peers match.

Debugs:

Debug voip h221 individual 23 (or all)


Troubleshooting: Capability exchange problems

Audio, video and bandwidth capabilities are exchanged between the video endpoints of the call.

This is different than a normal voice call, where codecs can be configured for a call, and the router will pick a codec.

The audio and video codec CLI can be entered on a voip dial-peer for the H.320 call, but it is used to strip all other codecs out of the capability exchange. If a codec list is used to specify a set of codecs, the endpoints will still have the choice to choose a codec (audio or video) from that list.


Troubleshooting: Capability exchange problems con’t

Things to check: The two endpoints do not have a matching codec between them. This is usually

not a problem. An audio or video codec CLI has been added to the voip dial-peer (for example

video codec H264), and one or both of the terminals cannot support this codec. H.320 calls can take several seconds to send caps, and when connected to a IP

video phone, the phone might time-out before capabilities are exchanged. This is common when connected to the callmanager. For the callmanager, the timer can be increased that it will wait for capabilities. This tends to happen when the H.320 endpoint is a Tandberg H.320 endpoint. Check “wait for TCS” box on CCM and increase “media exchange interface capability timer” and “media exchange timer” to 30 secs from their default values.

If connected to Tandberg H.320 (ver 3.x), make sure to have g711ulaw and g711alaw configured on the dial-peer using voice-class.


Troubleshooting: Capability exchange problems con’t

Debugs:

Debug voip ccapi inout

Debug h245 asn

Debug voip h221

Debug voip h221 raw/raw decode

Debug ephone video


Troubleshooting: Cannot establish audio or audio is not heard

This is an unlikely scenario but can happen.

Things to check: That the audio codec capabilities include a codec that both sides can support (see

Capabilities troubleshooting)

If connected to an H.320 terminal directly, the H.320 terminal might try to switch audio modes after the codec indication (audio OLC) has been sent. The Tandberg T1000 will do this occasionally (it always starts in G711 64k mode). The H.320 code does not support sending the IP leg an audio CLC, so if this happens audio will not be heard, or will be distorted. To help prevent this from occurring, the gateway will give the H.320 terminal a chance to adjust it’s audio codec at the beginning of the call, before sending an OLC to the IP leg and also configure codec in the dial-peer to force a single codec

Usually, H.323 video endpoints choose the audio codec based on the bandwidth of the call. If two H.323 endpoints are configured with different bandwidths across H.320 network, we can land into asymmetric audio codec. To avoid this, configure the codec on the dial-peer to force the endpoints to choose the same audio codec.


Troubleshooting: Cannot establish audio or audio is not heard

Workaround:

Set a codec filter in the IP dial-peer to force the call to use only one codec.

Debugs:

Debug voip h221 individual 5, 6, 11, 16, 22, 33 (or debug voip h221 all)

Debug h245 asn (if H.323 IP leg)


Show call active video brief (make sure that the audio packets count is updating)


Troubleshooting: Cannot establish video

No video can be established in one or both directions.

Things to check:

The bandwidth of the call. In low bandwidth scenarios, the video terminals may not activate video. Check to make sure that the bandwidth CLI is configured in the POTS dial-peer

correctly. Check to make sure that all secondary channels have been established (see

Secondary channel troubleshooting)

Make sure that there is a video codec match between the two terminals (see Capability troubleshooting). Remember that unlike audio, asymmetric video is supported.

Debugs:

Debug voip h221 individual 7, 10, 28 (or all)

Debug h245 asn (if H.323)


Debug ephone video/detail


Troubleshooting: Video is established, but cannot be seen

With this problem, video seems to setup normal, but one or both sides cannot see the video.

Things to check: The bandwidth of the call. In low bandwidth scenarios, the video terminals may

not be able to send enough video packets. An easy way to see this is to setup only a 64k call, and use G711. The video will establish, but will only have around 6.4k to transmit.

One or both sides do not send a Fast Video Update (FVU) to the other side, or doesn’t continue to send FVUs. FVUs tell the peer video terminal to send a new I-frame (complete picture). It has been observed on CUVA 2.0, it will only send one FVU to the H.320 terminal at the beginning of the call.

One or both sides have sent a flow control message to set video to 0. H.264 is supported only with Annex-A packetization. Check if H.264 OLCs are

opened with OID {0 0 8 241 0 0 0} in the media packetization section.


Troubleshooting: Video is established, but cannot be seen

Debugs: Debug voip h221 individual 11, 18, 19, 20, 21, 33, 45, 46 (or all) Debug voip h221 raw/raw decode Debug h245 asn1 Show call active video brief (check to make sure video packets

counts are updating)


Troubleshooting: Poor video quality

This can be difficult to diagnose the problem. One thing to remember is that H.320 is over a TDM connection, so the usual TDM impairments can affect the quality.

Things to check: Timing sources, and T1/E1 statistics. If the call is connecting over the

PSTN, bit errors can be occurring on other TDM legs of the call, that will not be shown at the gateway.

All the usual packet problems (lost, late, early, etc.)


H320 Video related Documents

Integrating Data, Voice and Video Services for ISDN Interfaces

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

Configuring Video Support for SCCP Endpoints

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmevideo.html#wpmkr1010947

Ipanema Product Requirements Document(EDCS-356201)

H320-Video System Functional Specification(EDCS-377413)

H320-Feature-TestPlan(EDCS-455952)

H320 Performance Test Results (EDCS-498209 )


Q&A