Solved: !?!! H323/SIP IP-IP Gwy transcoding won't work!!

globecomm-tle · ‎10-01-2010

(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

h323
sip

sccp local Loopback0
sccp
!
dspfarm profile 1 transcode

codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729br8
codec g729r8
maximum sessions 236
associate application SCCP

dial-peer voice 1000 voip
destination-pattern 1...
session protocol sipv2
session target ipv4:172.16.241.31
dtmf-relay rtp-nte digit-drop h245-alphanumeric
!
dial-peer voice 2000 voip
destination-pattern 2...
session target ipv4:192.168.12.12
dtmf-relay h245-alphanumeric
codec g711ulaw

gateway
timer receive-rtp 1200

gatekeeper

...

telephony-service
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.

Steven Holl · ‎10-04-2010

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:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml

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.

View solution in original post

tobin hawkshaw · ‎10-01-2010

even though you are not using cme etc.. have you tried adding this line to the sccp config: sccp ccm 10.1.1.1 priority 1

dont forget to no/sccp

globecomm-tle · ‎10-01-2010

sccp ccm 10.1.1.1 priority 1

telephony-service

sdspfarm units 1

sdspfarm transcode sessions 128

sdspfarm tag 1 3945-IPGWY-1

max-ephones 1

max-dn 1

ip source-address 10.1.1.1 port 2000

sccp ccm group 1

associate ccm 1 priority 1

associate profile 1 register 3945-IPGWY-1

keepalive retries 1

keepalive timeout 10

switchover method immediate

switchback method immediate

!

We do have this. We are using CME. Transcoding uses SCCP for communication. While we are not using CME to have any phones register to it, we use the “telephony-service” command to activate the appropriate portions of CME to allow SCCP to communicate with the DSP resources. 3 things are mandatory for CME… max-dn’s, max-ephones and ip source address. We already confirmed with Cisco that the max-dn and max e-phones need only be set to 1 or any random number for our application. The ip source address needs to be anything local to the router…. A loopback ip or one of the configured interfaces is fine. Any IP that the internal DSP resource can reach.

What do you mean by NO/SCCP? Take that out??

tobin hawkshaw · ‎10-01-2010

I just meant do a "no sccp" "sccp" but this isn't going to help now.what ios version are you running? do you know which pvdm module version you are running?

do you have:

sccp ccm 10.1.1.1 priority 1

or

sccp ccm 10.1.1.1 identifier 1 priority 1

globecomm-tle · ‎10-01-2010

We have:

sccp ccm 10.1.1.1 identifier 1 version 4.0

IOS Version:

Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M3, REL

System image file is "flash0:c3900-universalk9-mz.SPA.150-1.M3.bin"

PVDM Slot 0:

64-channel (G.711) Voice/Fax PVDM3 DSP DIMM PVDM daughter card

Hardware Revision : 1.0

PVDM Slot 1:

192-channel (G.711) Voice/Fax PVDM3 DSP DIMM PVDM daughter card

PVDM Slot 2:

256-channel (G.711) Voice/Fax PVDM3 DSP DIMM PVDM daughter card

Hardware Revision : 1.0

Steven Holl · ‎10-04-2010

First, make sure you specify the proper CM version in the 'sccm ccm ver ' line. I normally use version 4.x when registering to CUBE, since the capability versions really correlate with CM 's SCCP stacks. Version mismatch can cause the transcoder to either fail to register, or no audio to occur.

Also, you can't transcode g729a to 729b unless you configure it as a universal transcoder:

dspfarm profile 1 transcode univ

codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729br8
codec g729r8
maximum sessions 236
associate application SCCP

'sh sccp' shows the transcoder as registered, right? Can you post this output? You're missing the max-dn, max-ephone and 'create cnf' which you need to get the transcoder to reigster to CUBE/CME.

If you still have issues after this, we need to look at dial-peer matching and what codecs are offered on each leg, so get:

debug voip ccapi inout

debug ccsip mess

debug h225 ans1

debug h245 asn1

debug cch323 all

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

Steven Holl · ‎10-04-2010

Also, these lines need to match the device name; you specified diffrent names. This will also cause the xcoder to fail to register properly:

associate profile 1 register 3945-IPGWY-1

sdspfarm tag 1 MTP123456782012

Change one or the other so they both match.

globecomm-tle · ‎10-04-2010

Thank you for the reply back. I am sorry but that "associate profile 1 register 3945-IPGWY-1" does match up. I was pasting from old/new config file and confused the two.

Made slight progress

SIP (g711) --> H323 (g729a) signalling now works, but no audio both ways. Added "call start slow" on the H323 VOIP service. See traces below with stuff I highlighted but couldn't find much info on. Not sure if its a concern or not.

Attached

SIP.txt - SIP trace at the beginning, H323 trace at bottom

*Oct 4 15:18:18.719: //33/3B21AF2E80D7/SIP/Info/ccsip_gw_set_sipspi_mode: Setting SPI mode to SIP-H323

*Oct 4 15:18:18.719: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_event_handler: CC_R_SUCCESS_WITH_CONFIRMED

*Oct 4 15:18:18.719: //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 3 for event 3

*Oct 4 15:18:18.743: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_PROGRESS

*Oct 4 15:18:18.743: //33/3B21AF2E80D7/SIP/Info/sipSPI_ipip_codec_byte_transrating: NOT SIP-SIP CALL. Will be addressed in future.

SIP/2.0 500 Internal Server ErrorVia: SIP/2.0/UDP 172.16.241.31:5060From: "1211" <1211>;tag=B0D3BED-1F36To: <1990>;tag=2B1A94-19F6Date: Mon, 04 Oct 2010 15:18:18 GMTCall-ID: 3CBEF603-169E11CC-80DAB2CA-F96A07B4@172.16.241.31Timestamp: 731129416CSeq: 101 INVITEAllow-Events: telephone-eventServer: Cisco-SIPGateway/IOS-12.xReason: Q.850;cause=16Content-Length: 0

SIP-x.txt - SIP trace at the beginning, H323 trace at bottom, made a change to explicitly define using DTMF rtp-nte

*Oct 4 15:49:23.831: //67/92E96C9D8121/SIP/Info/sipSPIValidateGtd: tunnelledPtype != GTD

*Oct 4 15:49:23.831: //67/92E96C9D8121/SIP/Error/sipSPIAddCiscoGcid: Fatal Error in parsing CCB/Msg

*Oct 4 15:49:23.831: //67/92E96C9D8121/SIP/Info/sipSPIValidateTunnelData: RawMsg/QSIG Tunneling Not Enabled

*Oct 4 15:49:23.831: //67/92E96C9D8121/SIP/Error/sipSPI_ipip_set_history_info_header: Not SIP2SIP mode

info.txt - show active call details

Concerned why it shows 0 byte

CoderTypeRate=g729r8 pre-ietf

CodecBytes=0

IPIPGWY.txt - High level IPIPGWY debug output

*Oct 4 16:09:05.559: //72/531FDB77812C/H323/cch323_get_caps_chn_info: SIP->H323 xcoding, try to reserve transcoder for codec mismatch

*Oct 4 16:09:05.559: //72/531FDB77812C/H323/cch323_get_caps_chn_info: Xcoding needed, setup pref codec

*Oct 4 16:09:05.583: //72/531FDB77812C/H323/callproc_notify: Peer not ready so not starting TCP

Tried explicitly defining payload but no different

The UNIVERSAL command is not available in current IOS. We were contemplating upgrading the IOS.

Also attaching full 3945.txt as it is TODAY so its changed a lot since I posted this message. Essentially still the same but some extensions and dial-peer were changed. Please help. Thanks in advanced!!

globecomm-tle · ‎10-04-2010

debug voip ccapi inout

debug ccsip mess

debug h225 ans1

debug h245 asn1

debug cch323 all

Attached is the log you requested. I missed that part earlier.

Steven Holl · ‎10-04-2010

These debugs show a 711 call on both sides (so no transcoder necessary for this call). Peers 172 and 2001 are matched. See my previous points about using voice-class codec with a transcoder.

Also, see note about using voice-class codec at all with that version of IOS.

Steven Holl · ‎10-04-2010

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:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml

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.

globecomm-tle · ‎10-04-2010

(1700 rtr with FXS port) --SIP---> (IP-IP 3945 GWY) <---H323-- (C2600 Rtr with FXS port)

Steve, thanks very much for you detailed input and analysis. This is all in a lab setup. There is no outside provider. There is no call manager involved other then the local CME setup on the IPIP router to allow the transcoder to work. Let me try some of your suggestions and further research and reply back later today.

globecomm-tle · ‎10-04-2010

Steve,

Thanks to your help we now have G711/G729 transcoding working both ways!! But now when I carefully changed all my dial-peers to allow G729B/G729A transcoding, it fails. Is it because of this UNIVERSAL command needed?

Steven Holl · ‎10-04-2010

Yup. You need a universal transcoder for that scenario to work. See here:

http://www.cisco.com/en/US/partner/docs/ios/12_4t/12_4t15/it_unitr.html

-Steve

globecomm-tle · ‎10-04-2010

Let me clarify my statement a little. The "universal" option is there when I do "dspfarm profile 1 transcode ?". So I put in obviously "dspfarm profile 1 transcode universal". But when I do show run, the universal keyword is not there.