O básico de RSVP

Outra funcionalidade que dificilmente vejo implantada por ai é o RSVP. Então hoje eu vou postar um exemplo simples de configuração desse método de Call Admission Control.

Vamos supor que temos dois sites: Um Head Quarters (HQ) e um Branch Office (Br1). O CUCM fica no HQ, e todos os telefones dos dois sites se registram nesse cluster. Para interconectar esses dois sites temos um roteador em cada ponta fazendo um ponto-a-ponto. Se quiserem, é uma topologia facilmente montada no Dynamips...

Bom, seguindo as boas práticas de implantação, temos um Device Pool pra cada site, a region está setada para que eles se falem em G.729, e cada site tem uma Location também. E é nesse ponto que começa a nossa configuração.

Na Location, não vamos especificar a banda estaticamente, e deixamos o Audio Bandwidth como Unlimited. Porém, em Location RSVP Settings, marcamos a opção Mandatory (Video Desired) entre as locations. As opções que podemos setar lá são:
1. Mandatory: Se ela estiver marcada e não houver banda para uma chamada de video, ela falhará
2. Mandatory (Video Desired): Se ela estiver marcada e não houver banda para uma chamada de vídeo, ela fará o fallback para audio.
3. Optional: Se a chamada de audio ou video falhar por falta de banda, ela passará, porém com outra marcação de DSCP, que definimos dentro dos Service Parameters.
4. No Reservation: RSVP Desligado (opção default)
Obs: Caso você tenha tanto o Location-Based CAC quanto o RSVP habilitados, ele usará os dois. Primeiro checará a banda pelo Location-Based e depois fará o RSVP.

Bom, agora que habilitamos o RSVP, precisamos configurá-lo. Tanto que se nesse momento você fizer uma chamada de audio, ela falhará acusando falta de banda.

Primeiramente precisamos criar os nossos MTPs nos roteadores. Geralmente o MTP vai ser configurado em um roteador que está no meio do caminho do tráfego RTP, porque esse router vai finalizar o RTP nele, e gerar um outro fluxo para frente. No caso, aplicaremos nos nossos roteadores que fazem a conexão com os dois sites. A config do MTP será assim:

sccp local FastEthernet1/0
sccp ccm <IP CUCM> identifier 1 version 7.0+ (ou pelo menos 5.0.1)
sccp
!
sccp ccm group 1
 bind interface FastEthernet1/0
 associate ccm 1 priority 1
 associate profile 1 register mtp_hq / mtp_br1
!
dspfarm profile 1 mtp
 codec g729ar8
 codec g729r8
 rsvp
 maximum sessions software 10
 associate application SCCP

Obs 1: Você deve criar um profile para cada codec. Como aqui no caso estamos trafegando apenas G.729, apenas um profile foi criado.
Obs2: Essa configuração é de um software MTP, ou seja, não é necessário nenhum recurso de hardware, como PVDMs

Depois de criados os nossos MTPs, precisamos configurá-los no CUCM, como Enhanced IOS Software Media Termination Point. Depois colocamos eles dentro de Media Resources Groups, e depois nas Media Resources Group Lists. E aplicamos ao Device Pool de cada site.
Detalhe que o CUCM também tem um MTP dele, certo? E precisamos evitar o seu uso... temos duas alternativas: ou a gente desliga ele pelo Service Parameters >> Cisco IP Voice Media Streaming App, mudando a Run Flag para Off, ou colocamos esse MTP dentro de um MRG que ninguém tem acesso. Porque se você ele deixar fora de um MRG, a sua MRGL vai conseguir enxergá-lo.

Bom, feito isso, agora é só habilitar o rsvp na interface. Então na interface da "WAN", colocamos:
ip rsvp bandwidth X, onde X é a banda.
Para calcular esse X, utilize a fórmula:
X = (n * 24) + 16 para chamadas G.729, onde n é o número de chamadas
X = (n * 80) + 16 para chamadas G.711, onde n é o número de chamadas


Alguns debugs úteis para verificar o rsvp:
debug ip rsvp path
debug ip rsvp resv
show ip rsvp reservation