The initial SIP offer specifies G.729 for media, which the (original)
dial-peer can't negotiate since it is fixed at g.711. After setting an
appropriate inbound dial-peer, even though G711 is the primary choice in
the voice-class, G.729 is what is negotiated since the initial INVITE
specifies G729
Thanks
I saw an example and now it makes sense. I knew it was simple but I just wanted
to make sure
Randall
Sent from my iPhone
On Dec 28, 2011, at 12:42 AM, datucha123 datucha123
wrote:
> Please refer to the following great Posts, which will explain the SRR for you:
>
> http://blog.ine.co
Yep it is, but it still works. I think because the inbound dial-peer still has
g729 in it even though it's not the 1st choice.
John
-Original Message-
From: brajesh kumaR [mailto:brjku...@gmail.com]
Sent: Wednesday, December 28, 2011 11:58 AM
To: datucha123 datucha123
Cc: John McGaughe
But as per voice class codec still preference one is g711ulaw codec
which is on incoming dial-peer same codec as outbound peer.
On Wed, Dec 28, 2011 at 2:00 PM, datucha123 datucha123
wrote:
> Nice to hear that you have solved the issue.
>
> The solution is correct. When you a have a Voice-Class
What is the downfall if you cut and paste everything using the minimum sccp ccm
version 5.0 which all plab routers IOS supports. I have never had a problem
doing this.
Sent from my iPhone
On Dec 28, 2011, at 10:26 AM, "ccie_voice-requ...@onlinestudylist.com"
wrote:
> Send CCIE_Voice mailing
Gatekeeper license for 12.4-20T+ is very expensive.
HQ-RTR can run 12.4-15T without us students noticing any difference except
as you found out for the obvious cut-n-paste issues.
Interestingly, I accidentally misconfigured my home PSTN with 15.1 -
didn't notice any difference until I started ge
Problem solved.
H323 gateway was having some issue, I do not even know, but after about 1-2
minutes it started to send the correct Plan and Type through PRI.
Still, that's a very strange - Route start the sending configure Plan and
Type only after 1-2 minutes.
On Wed, Dec 28, 2011 at 5:12 PM,
Hello,
The H323 gateway has to pass the Number Type and Plan received from CUCM
(H323 call leg) to PRI (ISDN Call leg) by default. But my H323 is not doing
that.
I do not have any strange configuration, that might be causing the problem.
___
For more in
I think you're overstating a bit there.
in the lab. of course it's meaningless...
do not even use local route groups unless specifically asked for!!! use
specific gateways.
In real life! well it's different story.
say you have the following design:
client with 1 HQ site, and 10 smaller sites.
L
Anthony,
As I can see your config, it seems it will work properly, but the next hop
will have to trust that marking otherwise it will be remarked.
*Emanuel Damasceno*
CCNP Voice
On Wed, Dec 28, 2011 at 12:37 AM, Anthony Alba wrote:
> Hi,
>
> What is the definitive requirement for having mls
If I use separate Partitions for each site, then the idea of Local Route
Groups is meaningless.
On Wed, Dec 28, 2011 at 3:07 PM, George Goglidze wrote:
> Hi,
>
> You have to create two different partitions with two different TP-s. There
> is no other way around it.
> PT_PSTN_sa
> PT_PSTN_sb
>
Hi,
You have to create two different partitions with two different TP-s. There
is no other way around it.
PT_PSTN_sa
PT_PSTN_sb
I would suggest you never try to use same pattern, even RP for two
different sites in a lab, unless it's stricktly necessary by task
requirement.
Don't try to save space
Hello,
I am very confused with the Called Party Globalization along with Local
Route Groups.
Let's take a look at the following example.
We have two site in USA:
Site A with Area Code of 202
Site B with Area Code of 512
So, now we create the Local Route Groups - each Site Gateway is assinge
Please refer to the following great Posts, which will explain the SRR for
you:
http://blog.ine.com/2008/06/26/quick-notes-on-the-3560-egress-queuing/#more-141
http://blog.ine.com/2008/03/03/bridging-the-gap-between-3550-and-3560-qos-part-i/#more-84
On Wed, Dec 28, 2011 at 7:31 AM, Randall Crumm
You can also refer to Auto QoS, which creates the same kind of Port Trust
and Service Policy.
I also could not get the Full answer on that question, but here what I
have found out:
Only when the Policy-Map has the Trust statement, it will be mutually
exclusive with Port Trust.
In your case (as w
Nice to hear that you have solved the issue.
The solution is correct. When you a have a Voice-Class Codec that has the
G711 in it, then the Xcoder is not invoked as the G711 is supported by the
incoming dial-peer.
In such cases, you have to force the incoming dial-peer from CUCM (or any
other sou
16 matches
Mail list logo
