Been there -- done that... Confirmed it's G711 going out, here's a SIP trace from call start to call complete... (removed the ususal info)

see attachment

On your H.323 Gateway in Call Manager , do you have:

Media Termination Point Required

Wait for Far End H.245 Terminal Capability Set

Fast start enabled inbound and Outbound?

(do you have MTPs available)

MTP's are in, via hardware DSP's in the gateway and they are being used, confirmed with show sccp connections.

MTP is enabled, fast start in and out is also on, with G711ulaw,

Wait for Far End - tried both ways - no difference

From my own trace what I can see is that the ISR is cancelling the call for some reason -- the code points to codec -- but I don't see what the codec issue is.

What version of Call Manager are you running?

6.0.1

Could be something to do with the RTP parameters CUBE is passing onto CallManager. As soon as your SIP provider sends you 183 with SDP (I assume the following! - can you provide h323 debugs?) CallManager is dropping the call and the CUBE sends a CANCEL to the SIP provider.

Have a look at: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/prod_white_paper0900aecd8067937f.html

and

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb-gw-h323sip.html

For some tips.

Are you using media flow around or flow through? Anything interesting in the CallManager traces?

Regards,

Jonathan

Sorry didn't realise you were using CCM6, have you tried a SIP trunk to the CUBE?

Assume you're currently using h323 because in the SIP debug I only see the SIP provider side of the call, and h323 has been mentioned by previous respondents.

Regards,

Jonathan

Don't have CCM traces - which ones would be relevant?

H323 I can also pickup, I went through the cube document and everything seems right to me. Where do I check the media flow around vs flow through? and where would I set that?

I could use SIP trunk - however the gateway was already setup for other things (access to REAL PSTN via VIC cards) so I figured I could keep it.

For traces I'd start with CallManager, make sure at least h225, h245 and MTP are enabled. Possibly also IP Voice media streaming app.

You're probably using media flow through which is the default, unless you've configured 'media flow-around' in a dial-peer, global config or a voice class.

h323 debugs and CCM traces would probably be most helpful at this point.

Should be no problem sticking with h323, are there any firewalls or access lists between CCM and CUBE? Are your MTPs on the same router as CUBE? Traces will help show if the correct MTP is being selected and hopefully why the call is failing.

Regards,

Jonathan

Here is the H245

I find it interesting looking at the fields in the SIP messages...

Here is what I sent to the provider...

v=0

o=CiscoSystemsSIP-GW-UserAgent 4205 4127 IN IP4 MY-IP-ADDRESS

s=SIP Call

c=IN IP4 MY-IP-ADDRESS

t=0 0

m=audio 19108 RTP/AVP 0 101 19

c=IN IP4 MY-IP-ADDRESS

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:19 CN/8000

a=ptime:20

and here is what they sent... I wish I had more knowledge how to read them, I mean I can see the PCMU/8000 but the rest of it I cannot follow...

v=0

o=root 25690 25690 IN IP4 PROVIDERIP

s=session

c=IN IP4 PROVIDER IP

t=0 0

m=audio 12630 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=nortpproxy:yes

So perhaps a SIP trunk between the 2 may fix the problem.

Wonder if that will fix my funny DTMF issues as well.

Well -- switching to a SIP trunk fixed the problem. So it was something in the H323 config that was messing me up..

Time to see if it fixes my DTMF issues too..

-- update... Fixed my DTMF issues too (had to turn OFF the MTP)