Converting G.723 To G.729 - Cisco Community
- Cisco Community
- Technology and Support
- Collaboration
- IP Telephony and Phones
- Converting g.723 to g.729
Converting g.723 to g.729
06-25-2015 11:28 AM - edited 03-17-2019 03:28 AM
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.373sccp ccm CUCM:IP2 identifier 2 version 7.0sccp ccm CUCM:IP1 identifier 1 version 7.0sccp!
!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.
I have this problem too Labels:- Other IP Telephony
- All forum topics
- Previous Topic
- Next Topic
06-25-2015 11:51 AM
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.
5 Helpful Reply06-25-2015 01:09 PM
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?
0 Helpful Reply06-25-2015 02:26 PM
dspfarm profile 10 transcode universalhttp://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/it_unitr.html#wp1053397
5 Helpful Reply06-25-2015 02:30 PM
Thanks Chris for your reply will try that and let you know :)
0 Helpful Reply06-26-2015 01:38 AM
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?
0 Helpful Reply
06-26-2015 02:34 AM
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
5 Helpful Reply06-26-2015 03:06 AM
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.
0 Helpful Reply
06-26-2015 03:53 AM
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
5 Helpful Reply06-29-2015 11:37 AM
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
0 Helpful Reply
06-29-2015 09:14 PM
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
0 Helpful ReplyDiscover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide
Log in to Community
Quick Links Knowledge Articles Customers Also Viewed These Support DocumentsTừ khóa » G.729 Vs G.723
-
G.723 - Wikipedia
-
Which Is Better, G.723 Or G.729 - My CISCO Journal
-
Features Of The Most Common Codecs: G.711, G.723.1 And G.729A
-
Speech Codec (G.711, G.723, G.726, G.729, ILBC) - Actorsfit
-
Voice Codecs - GL Communications Inc
-
Install G.729 And G.723 Codecs | Documentation - E-MetroTel
-
What Is The Difference Between G.711, G.729, And GSM ... - Nexbridge
-
Which Codec Should You Use? - Kolmisoft Blog
-
Speech Codecs: Pros & Cons | This Blog Explain About Various ...
-
Voice Over Internet Protocol (VoIP) Technology
-
Perbandingan Kualitas Layanan Wireless VOIP Pada Codec G.711 ...
-
Video/Voice/Speech Codecs - Grandstream Singapore
-
Supported Codecs - Dialogic
-
Supported Codecs - Dialogic