cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
430
Views
0
Helpful
2
Replies

Calling intersite failing because of codec

Dfulgencio
Level 1
Level 1

Hi

,

I'm having a little problem.  I have a Call Manager Express 2921 at the Central Site.  I also have 9 remote sites conected to the Central Site.

In thoese remote sites  there are 1760 routers using FXS ports against PBXs. 

My problem is that when i try to make a call from the remote site to the central, the codec negotiated is g711ulaw.  This codec consume too many

bandwith, and i'm using frame-relay at remote sites.  So i'd like to use g729.  Now when i make the configurations and apply a voice-class codec forsing  to use g729  in the dial-peer pointing to the Central Site the call doesn't complete.

One intresting thing is that when i call from the CENTRAL SITE the call complete well using g729.  The problem is from remote to central.

Here is part of the configuration:

---------------------------------------------

call from remote to CENTRAL

----------------------------------------------

dial-peer voice 5 voip
description FOR DIALING TO PUEBLO CENTRAL
translation-profile outgoing strip8-to-central
destination-pattern 8....
voice-class codec 2
session target ipv4:10.234.144.1
incoming called-number 138
dtmf-relay h245-alphanumeric

voice class codec 2
codec preference 1 g729r8

----------------------------------------------------

call from CENTRAL SITE to remote

----------------------------------------------------

dial-peer voice 138 voip
description DIALINT TO TRUJILLO ALTO
translation-profile outgoing strip8-to-remotos
destination-pattern 8138
session target ipv4:10.138.1.1
voice-class codec 2 
dtmf-relay h245-alphanumeric

voice class codec 2
codec preference 1 g729r8

I also add captur i made using : debug voice ccapi inout

Thanks for your help,

2 Replies 2

Dennis Mink
VIP Alumni
VIP Alumni

I noticed in the CCapi INOUT output from a test call REMOTE--->CENTRAL:

*Jul  1 20:54:03.520: //1837/7F2733D68823/CCAPI/ccCallSetupRequest:
  Destination Pattern=8...., Called Number=4006, Digit Strip=FALSE
*Jul  1 20:54:03.520: //1837/7F2733D68823/CCAPI/ccCallSetupRequest:
   Calling Number=138(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=4006(TON=Unknown, NPI=Unknown),

so you called 4006 from 183

as you can also see, the correct dial peer is being hit:

*Jul  1 20:54:03.516: //1837/7F2733D68823/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=TRUE, Mode=0,
  Outgoing Dial-peer=5, Params=0x82612214, Progress Indication=ORIGINATING SIDE IS NON ISDN(3)

dial peer 5 is matched based on its incoming called number 183. Why are you not testing a number in the 8... range becuase this is the destination patterns, or have you made a typo and should that be 4....    ????? Or is your translation rule on dial peer 5 braking it down to a 4... extension?

Hope it helps

Please remember to rate useful posts, by clicking on the stars below.

Thanks Dennis,

Yes a breaking down to 4 digits with the translation rules, cause fromo remote site they use 8 as acces code.

I was looking for some documentation and i found that ip phone by default use g711ulaw.  At Central Site i'm using transcoding i don't know why

is not working right.  I'm gonna hardcode g729 in one phone at CENTRAL  to make a test.

If you know some other around solution to this issue, i'l appreciate your help.

thanks for your response.