[Cisco VOIP] Advies gevraagd voor migratie

[Flyduck]

Wij hebben een Cisco callmanager 4.1 draaien met daarop aangesloten zo een 2000 telefoons verdeeld over ca 150 locaties. Op veel locaties zijn de Cisco telefoons statisch geconfigureerd.
We hebben verder geen beheer over de routers op de locaties.

Nu gaan we een over naar versie 8, waarvan de omgeving nieuw wordt opgebouwd op een andere locatie [en subnet] binnen hetzelfde VPN.
De huidige omgeving werkt op H323 en de nieuwe gaan we aansluiten via SIP, beide via dezelfde ISP (dus nummerblokken kunnen makkelijk overgezet worden zonder portering)

Ik wil uiteraard op de meest makkelijke en snelle manier over van de oude naar de nieuwe situatie, waarbij we denk ik in 1x over moeten stappen omdat er heel veel intern word gebeld (en dat lukt niet als een deel op de oude en een deel op de nieuwe omgeving draait)

Het idee na veel overleggen is nu om op afstand op alle telefoons in te loggen (pfff....) en op alle telefoons de 1e TFTP server te laten verwijzen naar de nieuwe callmanager, en de 2e TFTP server naar de huidige 4.1 omgeving.
De nieuwe callmanager houden we onbereikbaar voor de telefoons doormiddel van een ASA.
Zodra de configuratie op de nieuwe omgeving compleet is verhuizen wel alle nummers naar de SIP trunk, zetten we de firewall open en geven alle telefoons een reboot.
Nu kunnen de telefoons de nieuwe omgeving wel bereiken en loggen in op de nieuwe server.

Ik zie alleen op tegen het omconfigeren van alle telefoons voor de migratie. Heeft iemand opmerkingen op deze methode, of al eens zo een migratie gedaan en weet wellicht een snellere manier om over te stappen?
Zelf zat ik nog te denken aan relay agents op de locaties met een centrale DHCP server, maar ik weet niet of dat uiteindelijke een snellere migratie oplevert omdat je toch alle telefoons af moet lopen.

[Verwijderd]

Flyduck schreef op vrijdag 04 februari 2011 @ 12:19:
...

Geen idee of dit de best practice is, maar de herconfiguratie van die Cisco phones moet toch op een geautomatiseerde manier kunnen gebeuren? Hetzij via een telnet/ssh script (zoek even op Expect), hetzij via SNMP write requests waarmee je de TFTP server(s) kan instellen.

[ Voor 69% gewijzigd door Verwijderd op 04-02-2011 12:48 ]

[Verwijderd]

Heb je al gekeken naar een export met BAT (Bulk administration tool).
Vervolgens een import op de nieuwe omgeving (misschien moet je de file even aanpassen) Dit lost in ieder geval het herconfigureren van de toestellen op. Zorg er wel voor dat je devicepools, CSS, partities, locations e.d. bestaan op de nieuwe omgeving anders gaan je BAT imports de mist in.

Heb je op dit moment centrale DHCP?
Gebruik je ISDN gatways of bedoel je dat je een H323 provider hebt en die laat swichen naar SIP?

[Flyduck]

Verwijderd schreef op zaterdag 05 februari 2011 @ 17:44:
Heb je al gekeken naar een export met BAT (Bulk administration tool).
Vervolgens een import op de nieuwe omgeving (misschien moet je de file even aanpassen) Dit lost in ieder geval het herconfigureren van de toestellen op. Zorg er wel voor dat je devicepools, CSS, partities, locations e.d. bestaan op de nieuwe omgeving anders gaan je BAT imports de mist in.

Heb je op dit moment centrale DHCP?
Gebruik je ISDN gatways of bedoel je dat je een H323 provider hebt en die laat swichen naar SIP?

Volgens mij gaf de export / import een probleem omdat versie 8 teveel verschilt van versie 4.
Alle configuratie moet dus opnieuw worden ingetypt, ook om vervuiling eruit te halen. Of bedoel je dat je speficifiek alleen de toestellen kan importeren, maar de telefoons verwijzen dan toch nog steeds naar de oude call manager..?

Een paar grotere locaties gebruiken wel DHCP (geen centrale), maar een centrale DHCP kan natuurlijk gerereld worden als het daarmee sneller gaat. De H323 provider doet inderdaad het switchen van de nummers, dit laatste moet dan gelijktijdig gebeuren met het omzetten van de toestellen.

[tlpeter]

Kun je geen dhcp relay gebruiker voor de kleinere sites?
Toestellen statis instellen is het het laatste wat ik zou doen en dan zeker met zulke aantallen.
Kun je geen sip trunk maken tussen de twee pbx'en?
Je kunt dan veel makkelijker migreren.
Je kunt dan per vestiging omgaan.

[Flyduck]

tlpeter schreef op zondag 06 februari 2011 @ 11:18:
Kun je geen dhcp relay gebruiker voor de kleinere sites?
Toestellen statis instellen is het het laatste wat ik zou doen en dan zeker met zulke aantallen.
Kun je geen sip trunk maken tussen de twee pbx'en?
Je kunt dan veel makkelijker migreren.
Je kunt dan per vestiging omgaan.

Als er een SIP is tussen beide PBXén dan blijft de intern bellen functionaliteit behouden?
Zoals ik al aangaf, kan ik wel relay configureren maar dan moeten toch alle toestellen omgezet worden wat net zoveel werk is.

Ik ben nog een beetje aan het uitzoeken en ik zit nu denken aan het wijzigen van de callmanager adressen in de config files van de telefoons op de TFTP server in de oude omgeving. Dus de telefoons zien een gewijzigde config file, downloaden deze en ontvangen het adres van de nieuwe callmanager. De migratie heeft dan al plaatsgevonden en dan kan het tftp adres achteraf worden aangepast op de telefoons. Kan dit zo gaan werken?

[MuddyMagical]

Flyduck schreef op zondag 06 februari 2011 @ 11:40:
[...]
Als er een SIP is tussen beide PBXén dan blijft de intern bellen functionaliteit behouden?
Zoals ik al aangaf, kan ik wel relay configureren maar dan moeten toch alle toestellen omgezet worden wat net zoveel werk is.

Ik ben nog een beetje aan het uitzoeken en ik zit nu denken aan het wijzigen van de callmanager adressen in de config files van de telefoons op de TFTP server in de oude omgeving. Dus de telefoons zien een gewijzigde config file, downloaden deze en ontvangen het adres van de nieuwe callmanager. De migratie heeft dan al plaatsgevonden en dan kan het tftp adres achteraf worden aangepast op de telefoons. Kan dit zo gaan werken?

Met een SIP trunk tussen beide PBX'en kun je inderdaad blijven bellen, maar let er even op dat je nummer reeksen wel goed moeten staan.

Volgens mij kan je het beste met de BAT tool gewoon alle telefoons vanaf scratch importeren. Als je van een 4x omgeving komt wil je echt wel alles even opschonen en 'vers' beginnen.

Ik ga er even vanuit dat je niet met SRST gaat werken aangezien je vertelt dat je geen toegang tot de routers en switches hebt. Klopt dat?
En hoe wil je het adres van de TFTP server gaan wijzigen? Alle telefoons nalopen?

[Flyduck]

MuddyMagical schreef op zondag 06 februari 2011 @ 11:52:
[...]

Ik ga er even vanuit dat je niet met SRST gaat werken aangezien je vertelt dat je geen toegang tot de routers en switches hebt. Klopt dat?
En hoe wil je het adres van de TFTP server gaan wijzigen? Alle telefoons nalopen?

Je laatste vraag is juist waarom ik dit topic heb geopend.
SRST gebruiken we niet, daar is onze infrastructuur ook niet op ingericht.
Ik ga is even kijken of een SIP trunk tussen de 4.1 en 8 omgeving interessant is.

[Verwijderd]

SRST heeft alleen nut als je gebruik maakt van ISDN voor de buitenlijnen. SIP op SRST heeft geen zin als je WAN (met je SIP trunk) eruit ligt.

Als trunk tussen de 2 callmanagers zou ik een niet gatekeeper contolled inter cluster trunk gebruiken. alleen moet je dan ff opletten welke nummerblokken je gaat doorsturen over deze trunk.

zelf zou ik eerst gaan kijken naar een centrale of decentrale DHCP. (dus eerst voor oude omgeving).
Vervolgens kun je dan per locatie (DHCP pool) het option 150 (TFTP) adres aanpassen. Handmatig instellen van TFTP op toestellen heb ik nog nooit gezien in omgeving met meer dan 10 toestellen.
Hoe gaat je nieuwe cluster er eigenlijk uit zien of gebruik je een enkele callmanager?

[TrailBlazer]

Hoe lang ben je bezig met het omconfigureren van een telefoon. Is dat meer dan 2 minuten per telefoon dan zou ik kijken of ik het kan scripten. Zo niet dan maar bot handwerk. Heb je geen stagiair Soms kan je gewoon beter gewoon door de zure appel heen bijten dan een week te gaan lopen klooien met allerhande scripts. Zorg dan wel dat je het vanaf nu zo configureert dat het de volgende keer wel automatisch kan.

[Verwijderd]

TrailBlazer schreef op zondag 06 februari 2011 @ 19:34:
Zorg dan wel dat je het vanaf nu zo configureert dat het de volgende keer wel automatisch kan.

Dat is natuurlijk nooit te realiseren.
Toen Cisco met callmanager 5 uitkwam kon je ook as-is upgraden maar een sprong van 4 naar 8 is niet zo makkelijk.
Als je nu door de zure appel heen bijt ben je wel van de vervuiling af. Heb je misschien al gedacht aan alle toestellen met een fictief intern nummer en gebruikers laten inloggen met extension mobility profiel. Dan ben je namelijk niet afhankelijk van een toestel (mac address) en een gebruiker.

[DGTL_Magician]

Verwijderd schreef op maandag 07 februari 2011 @ 22:49:
[...]

Dat is natuurlijk nooit te realiseren.
Toen Cisco met callmanager 5 uitkwam kon je ook as-is upgraden maar een sprong van 4 naar 8 is niet zo makkelijk.
Als je nu door de zure appel heen bijt ben je wel van de vervuiling af. Heb je misschien al gedacht aan alle toestellen met een fictief intern nummer en gebruikers laten inloggen met extension mobility profiel. Dan ben je namelijk niet afhankelijk van een toestel (mac address) en een gebruiker.

Dat valt ook nog wel wat mee. Ik heb een aantal klanten gemigreerd van 4 naar 7/8 en dat werkt prima.

[Flyduck]

Denk dat we zoals Trailblazer al aangaf gewoon alle toestellen maar gaan aflopen. Als we het met de hele afdeling doen valt het wel mee. Kan niet wachten om te gaan spelen met de phone proxy straks, thuis een toestel in je switch prikken en meteen bellen

[Verwijderd]

Moet je nog wel even een ASA of VPN concentrator hebben.

[tc982]

Je kan dit normaal gezien doen met een DHCP Scope in Windows , dan kan je alles altijd wijzigen wanneer je wilt.

Via extra DHCP Vendor ID en options kan je meestal alle settings meegeven ( TFTP, zelfs VLAN info voor de LAN en IPPHONE lan )

Dit heb ik zo gedaan voor een Aastra centrale.

Eerst een extra DHCP Scope aanmaken die je wilt gebruiken voor de Telefoons ( bv lan = 192.168.0.100 tot .200 en tel = 10.0.0.100 tot 10.0.0.200 ), vervolgens op de switches indien Layer 3 dhcp proxy aanzetten, of anders op de firewall.

In de scope van je LAN geef je dan de extra opties in van de centrale, normaal gezien de implementor moet die documentatie hebben. Ik had de volgende zaken ingesteld :
- IP van de SIP
- Poort van de SIP
- VLAN ID LAN
- VLAN ID LAN Priority
- VLAN ID TEL
- VLAN ID TEL Priority

Dit maakt dat als er een nieuwe telefoon word aangeshakeld, deze eerst in het normale LAN een IP krijgt, daar ziet hij de extra opties, geef het IP vrij, en reboot naar VLAN 7, daar krijgt hij dan van de DHCP een IP Address. Het leuke is dat je deze dan ook gewoon in de DHCP manager ziet staan.

Voor de clients hadden we dan een procedure voor het resetten van hun telefoon. Telefoon uitschakelen, opstarten met de <c> toets ngeduwd en dan factory default laten gaan. Deze herstart dan en na een reboot of twee vraagt deze de registratie info , geven ze hun intern nummer op , en ze zijn vertrokken. En je kan als IT'er lekker lui zijn

[DGTL_Magician]

tc982 schreef op woensdag 09 februari 2011 @ 13:01:
Je kan dit normaal gezien doen met een DHCP Scope in Windows , dan kan je alles altijd wijzigen wanneer je wilt.

Via extra DHCP Vendor ID en options kan je meestal alle settings meegeven ( TFTP, zelfs VLAN info voor de LAN en IPPHONE lan )

Dit heb ik zo gedaan voor een Aastra centrale.

Eerst een extra DHCP Scope aanmaken die je wilt gebruiken voor de Telefoons ( bv lan = 192.168.0.100 tot .200 en tel = 10.0.0.100 tot 10.0.0.200 ), vervolgens op de switches indien Layer 3 dhcp proxy aanzetten, of anders op de firewall.

In de scope van je LAN geef je dan de extra opties in van de centrale, normaal gezien de implementor moet die documentatie hebben. Ik had de volgende zaken ingesteld :
- IP van de SIP
- Poort van de SIP
- VLAN ID LAN
- VLAN ID LAN Priority
- VLAN ID TEL
- VLAN ID TEL Priority

Dit maakt dat als er een nieuwe telefoon word aangeshakeld, deze eerst in het normale LAN een IP krijgt, daar ziet hij de extra opties, geef het IP vrij, en reboot naar VLAN 7, daar krijgt hij dan van de DHCP een IP Address. Het leuke is dat je deze dan ook gewoon in de DHCP manager ziet staan.

Voor de clients hadden we dan een procedure voor het resetten van hun telefoon. Telefoon uitschakelen, opstarten met de <c> toets ngeduwd en dan factory default laten gaan. Deze herstart dan en na een reboot of twee vraagt deze de registratie info , geven ze hun intern nummer op , en ze zijn vertrokken. En je kan als IT'er lekker lui zijn

Cisco telefoons werken net even wat anders. Daarnaast gaf de TS aan dat de telefoons handmatig geconfigureerd zijn. Dan kijken ze niet naar DHCP opties.

[tc982]

DGTL_Magician schreef op woensdag 09 februari 2011 @ 13:12:
[...]

Cisco telefoons werken net even wat anders. Daarnaast gaf de TS aan dat de telefoons handmatig geconfigureerd zijn. Dan kijken ze niet naar DHCP opties.

Vandaar mijn procedure voor de gebruikers, dan kunnen ze zelf hun telefoon omschakelen. Zonder te veel kennis van zaken. We hebben toen voor 120 gebruikers er maar 3 zelf moeten doen.

[Flyduck]

Verwijderd schreef op woensdag 09 februari 2011 @ 12:51:
Moet je nog wel even een ASA of VPN concentrator hebben.

Die hebben we, maar moet nog wel een proxy license op helaas... maar van wat ik begreep krijg je 2 gratis licenties. Heb jij daar ervaring mee?

[DutchITMaster]

Nu ben ik niet zo bekend met cisco callmanager , maar er zal vast een manier zijn om deze met autoprovision te configureren . Misschien ( cisco kennende waarschijnlijk wel ) zit er wel een DLI achtig systeem in , je zou dan een configfile kunnen maken zodat de gebruikers in kunnen loggen met hun pincode/interne nummer ?

Ik weet dat Siemens / Swyx en sommige hosted platformen dit in zich hebben .
Het kan ook zijn dat dit op mac address gebeurt maar dat durf ik zo niet te zeggen .

Maar ik kan je wel vertellen dat als ik een systeem met +- 2000 toestellen heb draaien dat autoprovisioning een must is.

Wat ik zoiezo niet verstandig vind is dat er toestellen statisch zijn geconfigureerd. ze zullen nu nooit reageren als je een optie aan je dhcp toevoegd ( van bijvoorbeeld een TFTP server in je netwerk om firmware of config )

[ Voor 15% gewijzigd door DutchITMaster op 09-02-2011 22:03 ]

[Verwijderd]

Flyduck schreef op woensdag 09 februari 2011 @ 19:35:
[...]


Die hebben we, maar moet nog wel een proxy license op helaas... maar van wat ik begreep krijg je 2 gratis licenties. Heb jij daar ervaring mee?

nee heb helaas nog nooit een klant gehad waarvan personeel toestellen mee naar huis mag of wil nemen. Meestal wordt er gebruik gemaakt van doorschakeling naar mobiel of ip communicatior met een VPN client.

Ben je er al over uit of je centrale of decentrale DHCP gaat gebruiken voor het TFTP verhaal?
In CUCM 8 zit ook een optie voor DHCP alleen is deze iets minder mooi vormgegeven als een windows DHCP.

[ Voor 8% gewijzigd door Verwijderd op 09-02-2011 22:21 ]