Michael,
 
Don't you mean setting the 2nd dialpeer with a lower preference than the first 
dialpeer?  That was what i ended up doing, but i thought there may be another 
way to do it with the least number of dialpeer used.
 
Besides, it came up with some expected behaviors.  I noticed that when i had 2 
outbound dialpeers like that and tried to make the first call and monitored the 
gk call status.  The call went through using g711 as expected.  Then i 
disconnected the call, and immediately redialed the same number (or i even 
tried dialing a different number at the same site) and the call went through 
using g729.  Sometimes the call would use g711 as expected and other times it 
would use g729 even though there is only one active call.
 
And another weird thing is that, when the call went through using g711, i tried 
to answer the call but i got disconnected when i answered the call and 
automatically the phone rang again but this time the call went through using 
g729.  On my called phone, i saw 2 incoming line appearing on the phone from 
the same calling number, but only the second channel on my called phone is 
active and using g729.  The first channel was in a disconnected state.  That's 
the weirdest thing.  I've never seen that.
 
When the first call went through using g711 via the gk, the gk kept a record of 
the bandwidth being used for g711.  When i disconnected the call and 
immediatedly attempted another call, i think the gk has not enough time to 
release the bandwidth, and that was why the call went through using g729 codec. 
 If i waited long enough after disconnecting the call, then the call went 
through using g711 everytime.  So there is something strange going on the gk 
that i don't know about, or perhaps it was a bug.  Anyway... i'll try the same 
configuration on a different pod and see if the results can be duplicated.  
Thanks for your help.
 
JD


Subject: RE: [OSL | CCIE_Voice] Bandwidth Update with GKDate: Sat, 16 Feb 2008 
11:57:53 -0500From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; 
[email protected]






Use two dial-peers, set g711ulaw hard codec and max-conn of 1, the set 2nd 
dial-peer with higher preference and hard code codec to g729
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DevildocSent: 
Saturday, February 16, 2008 10:51 AMTo: CCIE Voice Online Study ListSubject: 
[OSL | CCIE_Voice] Bandwidth Update with GK
 
Hello, I know in CM, to update bandwidth automatically when calls are going 
through a gk, you'll have to modify the BRQ service parameter to true.  Does 
anyone know if there is an IOS command that does the same thing for an H323 
gateway?  Or if there is an IOS command that resets the bandwidth allocation on 
a gk as soon as the call is terminated? The reason being is that I experienced 
some codec selection issues with calls from an H323 gateway to CM via a gk when 
i used a voice codec class to prefer one codec type over another.  My prference 
in a codec class is to use g711 first and g729 as a second choice.  The 
interzone bandwidth is restricted to 144 (which is enough for 1 g711 and 1 g729 
calls).  Sometime a call would use codec g711 first (which is correct), and 
another time it would use codec g729 first (which is not preferred) even though 
there is only one active call. Any info is greately appreciated.  Thank you! JD



Climb to the top of the charts! Play the word scramble challenge with star 
power. Play now!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This 
email message is for the sole use of the intended recipient(s) and may contain 
confidential and privileged information of Cameron and its Operating Divisions. 
Any unauthorized use or disclosure is prohibited. If you are not the intended 
recipient, please contact the sender by reply email and delete and destroy all 
copies of the original message inclusive of any attachments. 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/

Reply via email to