(1700 rtr with FXS port) --SIP---> (IP-IP 3945 GWY) <---H323-- (C2600 Rtr with FXS port)
Ext1000 <---> Ext 2000
We can get H323/SIP calls to work in BOTH directions USING the same codec but anytime we try transcoding of any combination (g711/g729, g729a/729b) it fails! We switch the above setup doing SIP <--> SIP calls with transcoding it works.
I went as far as setting up GK/CUBE using VIA zones on the same IP-IP rtr.
I am beyond frustrated --- Working with a CCIE/CCVP expert and other voice experts and they cannot figure it out either. I am "secretly" asking for more help from you guys here ... Here is a snippet of the IP-IP gwy configuration. Not including the 1700 or 2600 rtr b/c they're just really simple configurations.
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sccp local Loopback0
dspfarm profile 1 transcode
maximum sessions 236
associate application SCCP
dial-peer voice 1000 voip
session protocol sipv2
session target ipv4:172.16.241.31
dtmf-relay rtp-nte digit-drop h245-alphanumeric
dial-peer voice 2000 voip
session target ipv4:192.168.12.12
timer receive-rtp 1200
sdspfarm units 1
sdspfarm transcode sessions 128
sdspfarm tag 1 MTP123456782012
ip source-address 10.1.1.1 port 2000
I ommitted what I felt was irrevelent config to this setup. There is NO CUCM or CME system involve. This is all purely SIP/H323 call signalling using all Cisco equipment. Please do not ask why we're trying what we're trying to do here because we're actually trying to emulate another setup similar to this but will be using non-cisco equipment and want a baseline of this working first.
I didn't look at the debugs, since they were collected individually which isn't going to help much. Run all those debugs at the same time, and collect off the router buffer. For no audio, does the call stay up indefinately if you leave it up? If so, you have a routing or NAT issue with the media stream, and use the output of 'sh call active voice br' while a call is up to see where you do and don't have tx and rx counters incrementing.
This isn't the cause of no audio, but you have some design issues that you will want to address on CUBE:
1. You need to do fast start into CM because your provider is doing early offer. Remove call start slow, and make sure inbound fast start is checked on CM.
2. For outbound calls, you want FS out, as well, so that we can do early offer to the provider. You'll need an MTP registered to CM to do that. Use an IOS software MTP if doing g729 on the CM-CUBE leg. If you are doing g711, you can use a CM software MTP.
3. You won't invoke a transcoder at CUBE if you match peers with voice-class codec. You need to be specific on your codecs if you want the transcoder to invoke. Also, voice-class codec isn't officially supported on CUBE until 15.1(2)T.
4. You need to use 'incoming-called number' or 'answer-address' statements so that you make sure you match the right inbound dial-peers for calls in each direction. I don't see any of those statements in there, which means you may be inboking the wrong dial-peer on the inbound leg, hence inheriting the wrong capabilities. You need to read this document and understand the concept of inbound dial-peer matching, and re-configure accoerdingly:
Use 'debug voip ccapi inout' to see what inbound peer gets mached in each scenario. It should be the CUCM peer on an outbound call, and the SIP ITSP peer on an inbound call from the PSTN.
Why are you doing h323 on the CM leg? Any particiular reason? The only valid one I see is if CM is 4.x. If you do SIP to SIP CUBE, you don't need an MTP for point 2 above, since you can configured early-offer forced. SIP-to-SIP CUBE is the recommended implementation to CM with SIP ITSPs now, since you don't have to require an MTP for outbound calls to have early offer on the SIP ITSP leg.