Converting g.723 to g.729

Kaushik Ray · ‎06-25-2015

Hello All

I have a setup as below and wanting to run g.723 on the phones connected to the PABX on the A side due to bandwidth restrictions on across the WAN Link.

The CUCM however does not have g.723 allowed through it; so was trying to setup MTP on the RTR A so that could convert g.723 to g.729.

But the calls are not getting established it rings but disconnects when picked up.

The router details

CISCO3925-CHASSIS

VWIC3-2MFT-T1/E1

2 X PVDM2-64

flash0:c3900-universalk9_npe-mz.SPA.153-3.M5.bin

the calls were working fine with the g.729 codec in on the RTR A

the relevant configs I have put in for the conversion are as follows:

voice service voip
ip address trusted list
ipv4 CUCM:IP1
ipv4 CUCM:IP2

!
voice class codec 2
codec preference 1 g723r63
!
voice class h323 1
h225 timeout tcp establish 3
!
!

!
sccp local GigabitEthernet0/2.373
sccp ccm CUCM:IP2 identifier 2 version 7.0
sccp ccm CUCM:IP1 identifier 1 version 7.0
sccp
!

!
sccp ccm group 1000
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 10 register xCoder
keepalive retries 5
switchover method immediate
switchback method immediate
switchback interval 5
!

!
dspfarm profile 10 mtp
codec g729r8
maximum sessions software 8
associate application SCCP
!

!
dial-peer voice 1000 voip
translation-profile outgoing profile1
preference 2
destination-pattern .T
progress_ind setup enable 3
session target ipv4:CUCM:IP1
voice-class codec 2
dtmf-relay h245-alphanumeric
playout-delay nominal 130
playout-delay mode fixed
fax-relay ecm disable
fax rate 9600
fax nsf 000000
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!
dial-peer voice 1001 voip
translation-profile outgoing profile1
preference 1
destination-pattern .T
progress_ind setup enable 3
session target ipv4:CUCM:IP2
voice-class codec 2
dtmf-relay h245-alphanumeric
playout-delay nominal 130
playout-delay mode fixed
fax-relay ecm disable
fax rate 9600
fax nsf 000000
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!

Am i missing any part of the config?

Any advise will be much appreciated.

Please let me know if you need any more relevant information.

Thanks in advance.

Chris Deren · ‎06-25-2015

Why are you using G723 and not G729? G729 is compressed and typically used across WAN, have not seen G723 used in decade.

MTP cannot transcode between codecs, you need Transcoder for it, and to transcoded between non-G711 it needs to be defined as universal transcoder.

Kaushik Ray · ‎06-25-2015

Thanks for your reply Chris

Actually there are 14 lines to be used in a 384K link. that is why the requirement is g.723 to be used.

I have changed the config to the following

dspfarm profile 10 transcode
codec g729r8
codec g723r63
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 8
associate application SCCP
!

sorry how would i define it as a universal transcoder?

Chris Deren · ‎06-25-2015

dspfarm profile 10 transcode universal

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/it_unitr.html#wp1053397

Kaushik Ray · ‎06-25-2015

Thanks Chris for your reply will try that and let you know :)

Kaushik Ray · ‎06-26-2015

Hi Chris

still having the same issues where the destination number is ringing when you pick it up it disconnectes after a couple of seconds the destination number again rings (through the second dial peer) and the same problem again.

Jun 23 09:09:42.386: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0034
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98382
                Exclusive, Channel 2
        Facility i = 0x91AA068001008201008B0100A1150202011C06042B0C090030098007436F6E736F6C65
        Calling Party Number i = 0x4980, '1600'
                Plan:Private, Type:Subscriber(local)
        Called Party Number i = 0x80, '07428328579'
                Plan:Unknown, Type:Unknown
        High Layer Compat i = 0x9181
*Jun 23 09:09:42.390: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8034
        Channel ID i = 0xA98382
                Exclusive, Channel 2
*Jun 23 09:09:47.350: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8034
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
*Jun 23 09:09:54.450: ISDN Se0/0/0:15 Q931: TX -> PROGRESS pd = 8 callref = 0x8034
        Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info
*Jun 23 09:09:57.474: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x8034
        Cause i = 0x80AF - Resource unavailable, unspecified
*Jun 23 09:09:57.494: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x0034
*Jun 23 09:09:57.494: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8034

Comes back with the above debug outputs/

Any thing else i need to change?

Vivek Batra · ‎06-26-2015

If I understand your call flow correctly, then you need transcoder at RB, not RA. This is b/c

1. You mentioned that at Call Manager side, G.723 is not allowed.

2. RTP over IP link should use G.723.

This means that RTP from RA to RB should use G.723, RB should transcode it to G.729 and then forward it to device behind call manager. Does it make sense in your scenario?

Now if that is the case, make appropriate universal transcoding configuration in RB (allow both G.729 and G.723).

Ensure that RB transcoder is registered with CUCM.

To invoke transcoder as per your requirement, region should be configured carefully to use G729 within same region (CUCM phones and transcoder RB) and G723 between different region (phones and gateway).

Allow only G.723 in the in/out dial-peers configured in RA.

I am suggesting this by assuming that CUCM trunk/gateway is pointed directly to dial-peer of RA (not to RB). If RB is being used as CUBE viz CUCM is pointed to dial-peer of RB then there could be some additional configuration steps for your scenario.

By the way, why don't you use G.711 at CUCM side and transcode it to G.723 between RB and RA....

Thanks

Vivek

R

Kaushik Ray · ‎06-26-2015

Thanks Vivek for your reply.

RTR A directly registers to the CUCM and both the dial peers on the CUCM are pointing to the CUCM.

The RTR A is setup as a H.323 gw on the CUCM. Would it not be possible to use g.723 on RTR A which gets converted to g.729 or g.723 at the CUCM?

Please let me know.

Vivek Batra · ‎06-26-2015

The RTR A is setup as a H.323 gw on the CUCM. Would it not be possible to use g.723 on RTR A which gets converted to g.729 or g.723 at the CUCM?

Yes, you can use G.723 on RA but how you will be able to convert it to G729 at CUCM?

CUCM can't do transcoding and change the codec. Since you want RTP to cross WAN using G723, there is only RB who can change the RTP from G723 to G729.

By the way, you will be able to invoke transcoder only if end terminal doesn't support G723 otherwise transcoder will never be invoked and RTP will flow directly between RB and end device (cucm).

Thanks

Vivek

Kaushik Ray · ‎06-29-2015

Hi Vivek

Thanks for your reply and sorry for the delayed response.

Just want to amend the drawing a bit more to make it a bit more relevant to the setup.

The above is a more relevant reflection.

The RTR A registers to the CUCM directly using its IP address on the WAN side interface, the RTR B is to route the traffic.

Please advise if the transcoding in this instance should be allowed on RTR A only.

Many Thanks again

Vivek Batra · ‎06-29-2015

You need transcoding where you want to save bandwidth. As you mentioned before, you want to utilize bandwidth more efficiently between RTR A and RTR B. This means that you would like to carry RTP in G723 from RTR A to RTR B.

Now at RTR B, you have two choice;

1. If end terminal (devices registered with CUCM) supports G723, you don't need transcoding at all, RTP can flow directly between RTA A and CUCM end devices.

2. In case end device doesn't support G723, RTR B can universally transcode from G723 to G729 (and viceversa).

RTR A will use DSP resources in this instance but for TDM to IP however IP to IP transcoding (dspfarm configuration) if required seems feasible only at RTR B.

Thanks

Vivek