DSP Transcoding with CME --- Transcoding not working

[CCC4046_2]

Hi,

I am on my CVoice learning track now and been trying to get the dsp transcoding up and running on my 1 x 1760 (PVDM 256K 20HD). Although everything I have configured looks right, the transcoding does not seem to work. Hence, here I come to post a question hoping someone could guide me through.

First off, the Network topology is as below.

Items:

2 x 1760 Routers (Only the remote router with enuff DSP resources to do the transcoding whereas the HQ one is just for call routing purposes).

2 x IPIC (Cisco Communicators 7.0)

IPIC (10.1.1.2) g711ulaw----> (10.1.1.1) HQ (20.20.20.1) ~~~~ 3M WAN Link ~~~~ (20.20.20.2) Remote (192.168.1.1) <-----  g729r8 IPIC (192.168.1.2).

My initial work was to test the transcoding.

1st, prior to the transcoding, two phones are only able to talk to each other when they have the same codec configured.

2nd, technically, if transcoding works on the Remote router, two phone should talk to each other. However, it seems like the transcoding did not kick in when phones (as above setup) calling eachother and what I got from the phone was busy tone.

Now I have attached my configs on both routers and please take a look and comment on it.

Your input will be highly appreciated.

Cheers,

[dksingh]

Don't think in this flow u can invoke a xcoder. Incoming IP leg (g711) into remote will

be immediately rejected due to cap-mismatch; u don't have a voip dialpeer on remote

so default dialpeer will be used (codec g729r8)

For xcoding to be invoked on CME, u'd need two IP legs, for example incoming g729

leg from another site to outgoing g711 to CUE/VM.

However try this as a test...on remote

Hardcode codec g729r8  under ephone for CIPC

dial-peer voice 1 voip
incoming called  2000
codec g711ulaw

Or u can come in g729 from HQ->Remote and then answer it on remote CIPC and park

the call. See if HQ CIPC gets a MoH.

[CCC4046_2]

Hi Dilip,

Thanks for your input.

Based on what you mentioned "u don't have a voip dialpeer on remote". However, I do have dial-peer defined on both routers for call routing.

HQ:

dial-peer voice 1 voip
destination-pattern 2000
session target ipv4:192.168.1.1
codec g711ulaw
!

Remote:

dial-peer voice 1 voip
destination-pattern 1000
session target ipv4:10.1.1.1
no vad
!

The only command i missed out is "incoming called  2000" on the remote router. Is that what forcing to default dial peer for matching the inbound call setup request?

Also, Cisco mentions that router or gateway matches any call setup element parameters in below order before failback to default dial peer 0.

1. incoming called-number

2. answer-address

3. destination-pattern

4. dial peer port

In my case, i did specify the destination-pattern on both end and thus defaul dial peer 0 should not come in to play.Is it correct?

Anyway, I will do what you advise and see how it goes.

Thanks alot.

[Steven Holl]

You're right, it uses destination pattern match off the *ANI* for an inbound match criteria, and the call should be coming from that extension, so it should match that peer inbound instead of pid 0.  Though, verify, and watch the output of 'debug voip ccapi inout' for a call, specifically the lines that contain 'peer='.

I bet the issue is a result of 'optimize for low bandwidth' being checked on the CIPC preferences?  Does the issue occurs with physical phones?

[CCC4046_2]

Hi Steve,

Thanks for your input.

I got to check it on the CIPC later and I have not tested on physical phones yet.

Anyway, I will come back with the debug capture as what you advised and let see what goes wrong.

Thanks,

[CCC4046_2]

Hey Guys,

Still no idea of the workaround.

I have attached some debug capture and could you please see if it does make any sense?

Thanks.....

[Steven Holl]

Need more debugs than that to diagnose; all that debug shows is that the call went out dial-peer 1, and the call failed with a codec mismatch.  At the minumum, we need the same debugs from the other side for the call.

Ideally, though, you'd also have h245 debugs off each side:

debug cch323 all

debug h225 asn1

debug h245 asn1

debug voip ccapi inout

debug ip tcp trans

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg

[dksingh]

Hmm...I do not believe you can invoke xcoder the way u r trying to test...

Coming in g711 and hitting an inbound voip dialpeer with g729 will cause

bearer cap mis-match and call to be released immediately.

Coming in g729 and then parking that call to see if a xcoder is invoked

for MoH will be a better test.

[Steven Holl]

Hah, yeah, that's right DK.  Overlooked that myself.

Codec mismatch needs to happen between inbound and outbound peer on the device with the transcoder.  Because we're going out peer 1 which has g711ulaw, the remote peer needs to have that codec configured on the inbound peer.  Essentially the outbound h323 peer of one router and the inbound h323 of the other side need to have the same codec.

The transcoder will get invoked if you force the codec mismatch betwen the inbound and outbound peers on the same device.  Which for that to happen, you need to configure the g.729 CIPC for 'codec g729' under the ephone, and have the h323 voip peer on that CME match g711ulaw.  Then have the transcoder registered to that device.

Hope that makes sense.

[dksingh]

Yeah, that what I said in my first response to this post

but seems I did not clarify it...perhaps..

[CCC4046_2]

Hi Dilip&Steve,

Thanks for your input.

As advised earlier, I did try hardcoding the codec g729 under the ephone, however, it does not seem an option under the ephone sub-command for configuring codec. Does this mean i need to hardcode the codec on the softphone end's setting?

Regards,

James

[Steven Holl]

CCC4046 wrote:
As advised earlier, I did try hardcoding the codec g729 under the ephone, however, it does not seem an option under the ephone sub-command for configuring codec. Does this mean i need to hardcode the codec on the softphone end's setting?

You're probably not running a version which supports that.  It was introduced in 12.4(4)XC and 12.4(9)T.  What version are you running?

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/command/reference/cme_c1ht.html#wp1080791

pod3-3825(config)#ephone 55
pod3-3825(config-ephone)#mac aaaa.aaaa.aaaa
pod3-3825(config-ephone)#type cipc        
pod3-3825(config-ephone)#codec ?
  G722-64K  Use G.722 64k bps voice codec
  g711ulaw  Use G.711 u Law 64000 bps voice codec (default)
  g729r8    Use G.729 8000 bps voice codec to save network bandwidth
  ilbc      Use iLBC 20ms voice codec

pod3-3825(config-ephone)#codec g729r8

[CCC4046_2]

Hey guys,

Phones can talk to each other now with different codecs set as advised earlier. However, my four different testings did not have the transcoder kicked in during each of the active call. Also, I have attached some debug output from the testing.

Thanks,

[Steven Holl]

Since H323 debugs weren't turned on, and we don't have an udpated configuration nor debugs from the other side, we can't draw conclusions from this output.

You'd need to collect CCAPI debugs from both sides during a call, and post the configuration (or at least dial-peer configs) from each side as well.

If the calls are working without a transcoder, though, unless you're invoking a codec other than you want to negotiate across the WAN, I'd say that's a good thing.

[CCC4046_2]

Hi Steve,

Yeah you are right, I will come back with more debug captures as cisco advised as well as the updated routers config.

http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094045.shtml#voipccapi

Meanwhile, I am just curious of what you mentioned earlier about "codec mismatch" found from my earlier post's debug capture (see attached).

Can you recall which particular line indicating the "mismatch" as I locate them?

Also, what does the disconnect cause code = 65 mean from the debug output?

Thanks