Redalyc

Sistema de Informacin Cientfica

Red de Revistas Cientficas de Amrica Latina, el Caribe, Espaa y Portugal

Parra L., Andrs; Guerrero, Fabio G. Esquema de redundancia y distribucin de carga de alta disponibilidad para la prestacin de telefona IP usando SIP Avances en Sistemas e Informtica, Vol. 6, Nm. 1, junio-sin mes, 2009, pp. 7-14 Universidad Nacional de Colombia Colombia
Disponible en: http://redalyc.uaemex.mx/src/inicio/ArtPdfRed.jsp?iCve=133112608001

Avances en Sistemas e Informtica ISSN (Versin impresa): 1657-7663 mprada@unalmed.edu.co;avances@unalmed.ed u.co Universidad Nacional de Colombia Colombia

Cmo citar?

Nmero completo

Ms informacin del artculo

Pgina de la revista

www.redalyc.org Proyecto acadmico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto

Esquemaderedundanciaydistribucindecargadealta disponibilidadparalaprestacindetelefonaIPusandoSIP Highavailabilityredundancyandloaddistributionschemefor thedeliveryofIPtelephonyusingSIP

1 2 AndrsParraL.,Ing. yFabioG.Guerrero,M.Sc. 1.IpsofactumS.A.ESP. 2.EscueladeIngenieraElctricayElectrnica,UniversidaddelValle,Colombia andresparra@ipsofactum.com fguerrer@univalle.edu.co

Recibidopararevisin16demarzode2009,aceptado20demayode2009,versinfinal28demayode2009

Resumen Enesteartculosepresentaunesquemadedistribucinde
carga y redundancia en la infraestructura de un ISP (Internet Service Provider) parala prestacinde servicios detelefona IP(ITSPs) sobre Internet usando el protocolo SIP (Session Initiation Protocol) garantizandonivelesdeaccesoalserviciosimilaresalaPSTN(Public SwitchedTelephone Network) y brindando una infraestructura de red escalable.Lasolucinseplanteaentrespartes:redundanciadelservicio ydistribucindecarga,rplicadebasesdedatosyredundancialgica a nivel de protocolo SIP en la interconexin con los proveedores de accesoalasredesconmutadas.

I. INTR ODUCC I N

Pa labras ClaveTelefona por Internet, Distribucin de Carga, Disponibilidad, SIP. AbstractInthispaperaredundancyandloadbalancingschemeatan

ISP (Internet Service Provider) infrastructure to provide IP telephony (ITSP)overInternet,guaranteeinglevelsofavailabilitysimilartothose of the PSTN (Public SwitchedTelephone Network) and providing network scalability is presented. The proposed solution is divided in threemainstages:redundancyandloadbalancing,databasereplication, and SIP level redundancy for interconnection with switchednetwork carriers.

ebido a los desarrollos en los ltimos 10 aos en la tecnologadelaVoIP(vozsobreelProtocolodeInternet), losserviciosdetelefonaIP(InternetProtocol)poseenhoyen da una serie de ventajas comparativas (costos de implementacin,facilidadesdeoperacinymantenimiento)y ventajas competitivas(costo parael usuario finaly servicios complementarios)conrespectoalatelefonabsicaconmutada. Unodelospuntosenloscualeslatelefonatradicionalaventaja porunmargenpequeo,peroconsiderableparalaexperiencia declientefinal,alosserviciosdetelefonaIPesladisponibilidad delservicio. Elparadigmadelaaltadisponibilidad(highavailability)en serviciosdetelefonasuponeunservicioporlomenosconuna disponibilidad del 99.999% de tiempo efectivo de servicio (comnmentellamado cinconueves).Alolargodelahistoriade la telefona tradicional por conmutacin de circuitos los fabricanteshicierondeesteindicadorelndicededisponibilidad delserviciocaractersticodelaPSTN(PublicSwitchedTelephone Network). En cuanto a arquitecturas orientadas a ofrecer alta disponibilidadCiscoSystemsproponeen[1]unaarquitectura basadaentecnologascomoDNSSRVRR(DomainNameSystem SRV Records), redundancia de gateways (pasarelas entre el

KeywordsInternet Telephony,Load Balancing,Availability, SIP.

RevistaAvancesenSistemaseInformtica,Vol.6No.1,Juniode2009,Medelln,ISSN16577663

RevistaAvancesenSistemaseInformtica,Vol.6No.1,Juniode2009,Medelln,ISSN16577663

mundoSIPylaPSTN)y proxies yelProtocolodeRedundancia de Enrutador Virtual (VRRP) [2]. Los conceptos aplicados dependiendo del modelo y tecnologa usados son los de inteligencia en el salto anterior el cual depende tanto de la inteligenciadelosagentesusuarioscomodelainfraestructura e inteligencia en el salto redundante el cual depende de la organizacindeservidoresyenrutadores.Laaplicacindeestas tcnicas se desarrolla en tres segmentos. El primero es la interconexinentrelosusuariosagentesSIPyel cluster dealta disponibilidaddeSIPproxies,elsegundoeslainterconexin entredosclusters deSIP proxiesy finalmentese analizala conectividad entre el cluster de alta disponibilidad de SIP proxies yel cluster de gateways.Laredqueseejemplificason nodosdeclientesqueseconectanaunodelos clusters deSIP proxies loscualesparaconectarseausuariosubicadosenotro nodoutilizandounainterconexinentre clusters.Finalmentese tiene un cluster de gateways que le dan paso a toda la infraestructuraparaqueseconecteconlaPSTN.Lasolucin finalestorientadaaunaimplementacindentrodeunaredde realocal(LAN)debidoaqueseutilizaelprotocoloVRRPel cualpermitenegociarunapertenenciaactivadeunadireccin IPparaunnodoentrevariosdispositivos.Seargumentaquese prefiereVRRPporencimadeDNSSRVRRdebidoaqueel primeropresentamenorescostosdeimplementacinynohay unadependenciadelainfraestructuraDNSdelaredLAN.Lo anterior no tiene relevancia en el Internet abierto ya que el sistema de resolucin de nombres es un sistema altamente distribuidoyautomticamentereplicado. Ohlmeierpresentaen[3]undiseobasadoenunafederacin geogrficamentedistribuidaenlacualseposeentresProxies SIP[4]ubicadosendiferentesciudadesloscualesatiendenlas solicitudesdecadaunodesususuariosyalavezsoportanlos clientesdesuscontrapartessisepresentaunafallaenalguno deellos.Estafuelaprimeraimplementacinreportadaenla literaturadeunasolucinderedundanciaydealtadisponibilidad paraVoIPsobreelprotocoloSIPbasadaenlainteligenciadel saltoanteriorlocualesmsadecuadocuandosedesarrollauna infraestructuraqueprestaserviciosenelInternetabierto. SinghySchulzrinne[5]proponenunasolucinbasadaenuna arquitecturahibridaentreunaarquitecturapuntoapunto(P2P)y SIPpuroaprovechandolacapacidadyrobustezdelossistemas P2Pdistribuidosylasaplicacionesdetelefonaqueprestanlos sistemas y servidores SIP tradicionales. La aplicacin que comunicalosdosmundosesSIPpeerlacuales,entrminosSIP, unProxyyanivelP2PunnododeunaDHT(DistribuitedHash Table)conorganizacincooperativautilizandoelprotocolo Chord [6].EsteelementopermiteausuariosagentesSIPcomerciales ingresaralainfraestructurasin realizarningn cambioen su implementacindelprotocolo. Laestrategia P2Pentrminos deseguridadno brindalas garantasnecesariasparaunaimplementacincomercialdebido a que nodos maliciosos del anillo DHT pueden afectar la comunicacin de una gran cantidad de usuarios y por ende

afectardemaneranegativaentrminosdedisponibilidadauna poblacinimportantedeclientes[5]. SinghySchulzrinnepresentanen[7]unadiscusinacercade lasdiferentesmetodologasdecontingenciaafallos(failover) ybalanceodecarga,loscualessonutilizadosparaelcasoen particulardelatelefonaSIPyproponenunaarquitecturabasada enDNSSRVRRparalacontingenciadefallosydosfasesde servidoresparagarantizarelbalanceodecarga.Laubicacin del servicio entre usuarios agentes y la primera fase de servidoresylaubicacindelservicioentrefasesdeservidores seplanteautilizandoDNSSRVRR. En la primera fase los SIP proxy realizan una seleccin utilizandoelhashdelaURI(UniformResourceIdentifier)para serreenviadalapeticinalasegundafasedependiendodela primeraletradelhash.Elalgoritmoutilizandoparaestehashes el SHA1. Estos servidores de la primera etapa estn configuradosparanomantenerlosdatosdelasesin(Stateless Proxy)locuallespermiterealizarlaredireccineindependizarse delamisma.Losproxiesdelasegundaetapaestnoperando paramantenerlosdatosdelasesinconsigo(StatefulProxy)lo cuallesobligaamantenerseenelmediodelasealizacinentre losusuariosagenteshastaqueestatermine. Laventajadeestaarquitecturaesquesedistribuyelacargaa niveldelserviciodelocalizacin[4]uniformementeentrelos elementosdelasegundafaseyaquecadaunoestosguardan losdatosdelocalizacindeunafraccindelapoblacintotal de usuarios. La primera fase tiene como objetivo entonces atenderlassolicitudesentrantesalainfraestructuraparaluego serdistribuidasestticamenteentreloselementosdelasegunda fase. Esta arquitectura no propone soluciones para la interconexin con gateways , carriers y proveedores de terminacinenlaPSTNysolopresentaunenfoqueorientadoa loquesedenominaPC2PC(llamadasentreusuariosagentes SIPdelamismared)elcualesunserviciogratuitoqueprestan todoslosoperadoresdetelefonaporInternet. Laarquitecturaquesepresentaenesteartculonosolose enfoca en la necesidad deconectividad entre usuarios de la mismaredsinoademspresentacomodesafoimportantepara el proveedor de servicios de telefona IP (ITSP) garantizar contingenciaafallosenlainterconectividadconlosproveedores determinacinenlaPSTNy carriers yaqueesteaspectoesla principal fuente de ingresos en este tipo de negocio. La arquitecturaplanteadaenesteartculoestsiendoimplementada enlainfraestructuradelproveedordeserviciosdetelefonaIP colombianoIpsofactumS.AE.S.P(http://www.ipsofactum.com). El alcance de este artculo est enfocado en el lado del proveedor de servicios de telefona por Internet (ITSP) y la organizacinaniveldesoftwaredelaoperacindeunsistema detelefonaSIP.Sepresentanbasesprcticasparapermitiraun operador de servicios de telefona IP usando protocolo SIP obtenerredundancia,distribucindecargayescalabilidadpara lograrnivelesdeaccesoalosserviciosdetelefonasimilaresa

EsquemaderedundanciaydistribucindecargadealtadisponibilidadparalaprestacindetelefonaIPusandoSIP ParrayGuerrero.

losdelaPSTN.Noseconsideranproblemas,limitacionesy retosdedesarrolloenelladodelcliente,comointerrupciones en el servicio de Internet, errores del usuario y fallas en el software,hardwarey/ofirmwaredelterminalSIP.Elestudio detalladodelasmedidasdedisponibilidadparaestaarquitectura estmsalldelalcancedelpresenteartculo. Laseccin2describebrevementelaarquitecturainternade un conmutador de software para VoIP y sus elementos y funcionalidadesparaproveerserviciosdetelefonaIP,laseccin 3presentalaaplicacinparalograrobtenerredundanciacon contingenciaafallosydistribucindecargaenlainfraestructura graciasalautilizacinderegistrosDNSdeubicacindeservicio (DNSSRVRR).Laseccin4describelametodologaparalograr lasincronizacindelasbasesdedatosconlainformacinde contabilidadyenrutamientoaredesPSTN.Ademssepropone unaestrategiaparaofrecerescalabilidadycontingenciaafallos a nivel de bases de datos. En la seccin 5 se proponen dos algoritmos para garantizar altos niveles de terminacin de llamadasexitosasconredesexternasenlaconectividadcon terceros (proveedores PSTN y carriers). Finalmente en la seccin6seexponelaarquitecturapropuestaensutotalidad, seanalizancasosaniveldesealizacinSIPdentrodelamisma teniendo en cuenta fallos de conexin y se valida la alta disponibilidaddelsistemafinal.

B.Motoresprincipales
Enestebloqueseencuentranubicadoslosdiferentesmotores bsicos a nivel de protocolos de VoIP (SIP y H.323). Estos elementos permiten realizar todo tipo de conmutaciones, conversionesdeprotocoloyademscomoenelcasodelB2BUA (BacktoBackUserAgent)[4]generarporsisolosnuevassesiones devoz.Enlaarquitecturaplanteadaenesteartculosonimportantes losmotoresSIP Proxy/Location/Registrar yelB2BUA.

C.Funcionalidad
Aqu se encuentran todaslas herramientas y aplicaciones para el tratamiento de numeracin, planes de marcacin, terminacin,enrutamientoyAAA(Autenticacin,autorizacin ycontabilidad).ElconvertidordecodificadoresdeVoz(RTP Proxy)noesrelevanteparalapresenteinvestigacinyaquese debe asumir que los dispositivos son compatibles en sus codificadoresdevoz.

D.FuncionalidadOpcional
Estainterfazdeprogramacindeaplicaciones(API)permite realizareldesarrollodelcontrolytomadedatosentiemporeal delaarquitecturadealtadisponibilidadpropuesta.

E.InterfazdeAdministracinyusuarios
Enestebloqueseencuentranlasherramientasdepresentacin vaWEBparalosregistrosdetalladosdellamadas(CDRs)ycontrol deparmetrosdelsistemaporpartedeladministradordelmismo.

II.ARQUITECTURADE UN CONMUTADOR DE SOFTWARE DE VO IP (SOF T SWI TC H )

EnlaFigura1sedescribelaarquitecturadeun sofswitch de VoIPestndar.

III. REDUNDANCIA DE SERVICIO Y DISTRIBUCIN DE C AR G A

Paraelmanejodelaredundanciaplanteadoenesteartculo seempleanlastcnicasDNSutilizandoregistrosdeservicios DNS SRV RR [8] para ubicar servidores SIP [9] los cuales permitendistribuircargaalosservidores,asignarprioridada nodoscentralesSIPeignorarservidorescadosenelmomento deresolvereldominiodelserviciodetelefona.Estatcnicase conocecomointeligenciaenelsaltoanterior.Losregistrosde servicioDNSSRVRRtienenelsiguienteformato:
Figur a 1. Arquitectura del Softswitch.Arquitectura diagramada de un softswitch de voz sobre ip de nueva generacin segmentado desde las capas de protocolos hacia la capa de presentacin y aplicacin.

Servicio._protocolo.nombreTTLSRVPrioridadPesoPuerto Destino.
Enelformatoanteriorseobservanlosdiferentescamposque componenunregistroSRV,dondePrioridadsignificaenqu orden se debe contactar al destino (el de menor nmero se contacta primero) y Peso es un mecanismo de seleccin de servidores(eldemayornmerotienenmayorprobabilidadde recibirpeticiones).Graciasalanaturalezadeestetipoderegistros sepuedeofreceraprioriredundanciaenelaccesoalservicio siempreycuandoelclienteSIPsoporteDNSSRVRRlocualse cumple para la mayora de fabricantes de dispositivos y softphones SIP (Cisco, Linksys, Sipura, Grandstream, CounterPath,Polycom,etc).Paralogrardistribucindecarga se necesita configurar el campo Peso con respecto a las

Acontinuacinsedescribebrevementecadaparte:

A.Protocolos
Este bloquese encarga de brindarcompatibilidad con los diferentesprotocolosdesealizacindeVoIP,protocolosdela capadetransporteorientadosaVoIP,ydetransmisincomo porejemploTDM(TimeDivisionMultiplex)yPRI(PrimaryRate Interface) de la red de servicios digitales integrados. La discusin en esta investigacin se centra en el protocolo de inicializacindesesinSIP.

10

RevistaAvancesenSistemaseInformtica,Vol.6No.1,Juniode2009,Medelln,ISSN16577663

capacidadesdecadaunodelosdestinos(ServidoresoGranjas deServidores)ylasnecesidadesdelainfraestructura(Velocidad deConexin).ParaelcasodelaFigura2seobservaquese tienendefinidosdosdestinosparaquelosclientesbusquenel servicioSIP(sobreTCP,UDPoTLS):sip1.ipsofactum.comy sip2.ipsofactum.com.Ademssip1ysip2sonregistrosDNS tipoAquepodranserdeclaradoscomounagranjadeservidores.

enrutamiento, costos,tarifas y proveedores.Todo softswitch poseecontroladoresparalaconexincongestoresdebasesde datoscomoMySQL,PostgreSQL,LDAPyOracle. Paraesteestudioenparticular,seutilizaelgestorMySQL [10]yaqueestepresentaventajasdeestabilidad,portabilidad, suusoeslibrebajolicenciaGNUGPL(LicenciaPblicaGeneral) yhaprobadosucompatibilidadconelconmutadordesoftware deIpsofactum. ElmotordebasesdedatosMySQLposeefuncionesymodos deoperacinquepermitenrealizarrplicasdebasesdedatos. Estoselogragraciasaqueeldemonio mysqld puedeejecutarse generandoregistros(log)binariosdetodassusoperacionesy comandosSQL(StructuredQueryLanguaje).Enunesquema de rplicas comoel que utiliza MySQLexisten dos agentes diferenciados:elMaestro,sobreelcualseejecutantodaslas tareasdelecturayescriturayel Esclavo, sobreelcualserealizan las lecturas de los datos y cuya informacin permanece actualizadagraciasaqueesreplicadadesdeelMaestro.Esto permiteunbalanceodecargaparatodaslassolicitudesdelos AgentesUsuarios,unasolucinenlacualsepuedegarantizar escalabilidadentrminosdelaconectividaddenuevosagentes a la infraestructura. En la Figura 3 se describe el esquema propuestoparagarantizarescalabilidad.En[11]seplanteaun esquemasimilardereplicasdedosvaselcualesescalablea solamentedoselementosredundantes.

Figur a 2. Ejemplo redundancia y distribucin de carga de servidores SIPutilizando DNSSRV RR.

EnlaFigura2seobservaqueeldestinosip1tiene4veces msdepesoqueeldestino sip2.Estosignificaqueel80%de lasveceslaspeticionesvanaserenviadasasip1yel20%a sip2.Estaesunametodologadedistribucindecargautilizando elcampoPesodelregistroDNSSRVlacualtalcomosedefine enelRFC2782[6]representainformacinestticadelestiloEl servidorAposeeunamejorCPUoElservidorBcuentacon uncanaldedatosmsrpido. LautilizacindelosSRVRRpermitedefinirredundancia,peso yprioridadparalaubicacindeserviciosespecficosdefinidos por la IETF en el RFC1700 (Assigned Numbers STD2) y actualizados en la base de datos de la organizacin IANA (InternetAssigned NumbersAuthority). Basndose en las pruebas realizadas se tiene como conclusin que se pueden definirporDNScualquiercantidaddeservidoresredundantes oinclusive granjaslo cualtraslada elproblema finala la sincronizacin de los mismos, el dimensionamiento de la infraestructurayloslmitespropiosdeesta.

Figur a 3. Esquema de replicas garantizando escalabilidad.

IV. SI NCRO NIZACIN DE BASE S DE DATOS

Labasededatosesunelementocrticoparaunsistemade VoIPyaqueenlamismasealmacenatodalainformacinpara realizarAAA(Autenticacin,AutorizacinyContabilidad)en tiempo real, adems de almacenar los parmetros de

Como se observa en la Figura 3, uno de los agentes est configuradocomoMaestroderplicasylosrestantesposeen unadenominacinde Esclavos paraesemomentoenparticular. Las operaciones de escritura se dan nicamente sobre el Maestro. Lasoperacionesdelecturasepuedendartantosobre el Maestro comolos Esclavos.Comoreglageneralparaevitar sobrecargas en el agente denominado circunstancialmente Maestro,elclienteMySQLdellosagentesredundantesque poseanunEsclavoMySQLdebenrealizarlasoperacionesde lecturasobrelabasededatoslocalynosobrelabasededatos deotroagente.Porlotantosoloelagenteredundantealque perteneceeldenominado Maestro MySQLrealizaoperaciones

EsquemaderedundanciaydistribucindecargadealtadisponibilidadparalaprestacindetelefonaIPusandoSIP ParrayGuerrero.

11

delecturasobre labasededatos delMaestro MySQLde la arquitectura. Debidoaqueunsoloagentenopuedegarantizarunaalta disponibilidadporsmismoparaelserviciodebasesdedatos deMySQLeventualmenteel Maestro puedesalirdelnea.Para este caso, el motor MySQL cuenta con funciones para reconfigurar el servicio de bases de datos de cada agente cambiando el Maestro de rplicas e informar a los dems agentesparaqueestossereconfigurenyprocedanaleerlos registrosbinarios(logsbinarios)delnuevoMaestrocomose muestraenlaFigura4. Se debe tener en cuenta que una vez el agente que se encontraba en falla vuelve en lnea, este no debe recibir peticioneshastaqueestsincronizado.El Maestro quetomel control debe mantenerlo hasta que se presente una falla nuevamente.Ahora,sialgunodelosesclavosfallaesnecesario sololaresincronizacindel Esclavo enfallaparaqueelsistema entreenoperacinnormal. Con este enfoque y aprovechando las caractersticas y funcionesdeunmotordebasesdedatosconMySQLsegarantiza que la informacin est sincronizada en todos los agentes redundantes para mantener los datos del sistema AAA y las estadsticas del servicio de telefona IP constantemente actualizadosydisponibles,mientraselserviciodelocalizacin SIPquepermitecomunicacinentreusuariosdelamismaredyel serviciodeenrutamientoaredesexternaspermanezcanactivos.

V. REDUNDANCIADE PROVEEDORES DE TERMINACIN EN LA PSTN

Unodelosretosaenfrentareslograrmaximizarelporcentaje determinacindellamadasaredesexternas,estoselogracon unaestrategiadeproveedoresredundantes.Internamenteen todo softswitch elmotorprincipaldelconmutadordebegenerar un reporte del estado de las llamadas y de cada canal. Los estadosgeneradosporlosintentossedescribenacontinuacin. 1) ANSWERED:Este estado describe quela llamada fue correctamentecontestada. 2)NOANSWER:Lallamadanofuecontestada.Dependedel tiempomximodetimbradopermitidoenelsistema. 3)BUSY:Elabonadoestocupado. 4)CANCEL:Elintentodellamadafuecanceladoporelusuario. 5)CHANUNAVAIL:Elcanalnoestdisponibleyaquela numeracinesincorrecta. 6)CONGESTION:Larutaestcongestionada. Elalgoritmodesarrolladotienelacapacidaddedetectaren tiempo realel estado delcanal y basndose eneste realizar reintentossecuencialmente oenparalelopara maximizarel porcentajedeterminacindellamadasexitosas. Elcomandodemarcacinposeelassiguientesvariablesenla basede datos:

Host:DireccinIPonombrecannico. Protocol:SIPoTCP(SIPsobretransporteTCP),SIPoUDP (SIPsobretransporteUDP)oSIPoTLS(SIPsobretransporte TLS). Port:Puertodeconexin. Prefix:Prefijodemarcacin. Telnumber:Nmeromarcadoporelcliente.

Enelsoftswitch seejecutaelcomandodemarcacinconel formato:

Dial(Protocol/PrefixTelnumber@Host:Port)

A.Algoritmoparaenrutamientoserial
Seiniciaejecutadoelcomandodemarcacinenelsoftswitch elcualcreaunacanaldeconexin.Unavezelcanalescerrado sedebeestablecerlarazndeterminacin(oestado)delmismo. SielestadodelcanalesBUSYoANSWEREDelalgoritmo terminayseprocedeagenerarelreportedelallamadaalsistema decontabilidad.Siporotraparteelestadodelcanalesdiferente alosestadosmencionadosanteriormenteseprocedeaejecutar otrocomandodemarcacinconlainformacindelproveedor quesigueenelordendeprioridaddefinidoenelsistemade enrutamiento del softswitch paracada ruta. Este proceso se

Figur a 4. Contingencia del sistema de rplicas en caso de falla de maestro.

12

RevistaAvancesenSistemaseInformtica,Vol.6No.1,Juniode2009,Medelln,ISSN16577663

realizatantasvecescomoproveedoresinscritossetenganenel sistemaderedundanciacomosemuestraenlaFigura5.Este mtodopermitedefinirunapreferenciaestticadependiendo decalidadycostosparacadaunadelasrutas,porlotantose recomiendautilizaresteenfoqueparapriorizarlautilidad.

Figur a 6. Ejemplo de algoritmo de proveedores redundantes en paralelo.

Utilizandoestetipodealgoritmossemaximizalacapacidad deofrecerinterconexinyterminacinconredes PSTNoptimizandodesdeunenfoqueprcticoenlaprestacin deserviciosdetelefonaporInternetelndicedeterminacin dellamadasexitosasASR(AnswerSeizureRatio),tiempoo latenciadepostmarcacinPDD(PostDialDelay)ybrindando lacapacidaddemejorarlosporcentajesdeutilidaddeestetipo de negocios.

VI. ARQUITECTURAPROPUESTAY CLCULO DE LA DISPO NIBI LI DAD

Figur a 5. Ejemplo de algoritmo de proveedores redundantes en serie.

B.Algoritmoparaenrutamientoenparalelo
Seejecutasimultneamentetantoscomandosdemarcacin comoproveedoresestninscritosporrutatalcomoseilustra enlaFigura6.Losproveedoresseinscribenenelsistemade enrutamientointernodelsoftswitch.Elprimerproveedorque responda la llamada queda en propiedad del canal e inmediatamentesecierranlosotroscanales.Dadoqueesmuy probablequelamejorrutadisponibleyportantoposiblemente lamscostosa, enlaceprimerolallamada,se debeteneren cuentaqueesteenfoqueesadecuadoparamejorarlosndices determinacindellamadasexitosas(%ASR)ytiempoolatencia depostmarcado(PDD),locualespenalizadoentrminosdela utilidadmonetaria.

Lafigura7muestralaarquitecturaplanteadalacualsebasa en agentes redundantes, cada uno de los cuales posee un softswitch consurespectivabasededatos.AnivelSIPtalcomo seexpusoenlaseccin2,el softswitch poseecomounodesus motoresprincipales un ProxySIPque seencarga derecibir directamente todas las peticiones SIP para procesarlas y redireccionarlasasudestino.Comoreglageneralcadacliente delproveedordetelefonaIPposeesolamenteundispositivo SIP(softphone,hardphoneoanalogtelephoneadaptor )por lnea IP registrada en el sistema el cual es aprovisionado medianteTFTP(TrivialFileTransferProtocol)oHTTP(Hyper TextTransferProtocol).Estacaractersticaevitaviolacionesde seguridadsobrelosusuariosdelproveedoryaquelosmismos no conocen la dupla usuariopassword SIP con la que se autentica el dispositivo SIP con la infraestructura ni los parmetrosdeconfiguracinyademsliberaalainfraestructura delidiarconmltiplesdispositivosparaunmismousuarioSIP, lacualseconocecomo forking.Lafigura7muestralaarquitectura planteada en su totalidad indicando todos los elementos presentes discutidos.

EsquemaderedundanciaydistribucindecargadealtadisponibilidadparalaprestacindetelefonaIPusandoSIP ParrayGuerrero.

13

Figur a 9. Flujo de llamada hacia la PSTN.

Figur a 7. Arquitectura de alta disponibilidad propuesta.

Acontinuacinsemuestrandosejemplosdeflujodellamadas sobrelainfraestructurausadaporIpsofactum.EnlaFigura8se puede observar la capacidad de contingencia a fallas de la arquitecturaeneventosenloscualesserealizaunallamada dentrodelamismaredyenlaFigura9unoenelcuallallamada tienecomodestinolaPSTN.

Figur a 8. Flujo de llamada entre usuarios de la red.

EneldiagramadelaFigura8seobservaqueelproxyno mantieneelestadodelasesin(statelessproxy)locualsignifica quelasesinseestablecesinimportarelagenteredundante querecibelaspeticionesSIP.

EnelejemplodelaFigura9,el proxy mantieneelestadodela sesin ( stateful pr oxy) ya que esta es redireccionada internamentealB2BUAquerealizaelenrutamientoalasredes PSTNyejecutaelalgoritmoderedundanciadeproveedores ascomolosscriptsAAA.UnB2BUAesundispositivoSIP querecibepeticionescomounusuarioagenteservidor(UAS) ylasprocesacomounusuarioagentecliente(UAC),porlo tantoporcadasesinquerecibesegeneraunanuevasesin haciaeldestino.Estecomportamientoesextremadamentetil pararealizartareasdecontabilidadentiemporeal,autorizacin desesionesdependiendodedatosinstantneoscomosaldos o permisos y para proteger informacin reservada como la direccinIPdeautenticacinconelcarrier ylosprefijosde marcacin. Enlosdoscasosanterioressepuedeobservarquelasesin de audio inicializada no es comprometida por fallos en la infraestructurayaqueelcaminodelainformacinRTP(Real TimeProtocol)[12]estdefinidoentrelasdireccionesIPdela fuente y el destino sin pasar en ningn momento por los elementos redundantes de la infraestructura. En el caso particulardeunasesindevozhacialaredPSTN,sisepresenta unafallaen elagente redundantequeiniciaestasesin,se procedeagenerarunregistrodefalladelasesinysecorrige lacontabilidadunavezserecibanlosreportesCDR(CallDetail Records)delproveedor. Pararealizarelclculodeladisponibilidaddelsistemase debeasumirqueeltiempoparaquefalleunsistema(MTTF MeanTimetoFailure)esmuchomenorqueeltiempoparaque serepare(MTTRMeanTimetoRecovery).Debidoaquese poseenagentesredundantesenloscualeslabasededatosy el softswitch compartenelmismoservidorladisponibilidaddel A sistemaes(1(1Da) )dondeDaeselfactordedisponibilidad decadaagenteyAeselnmerodeagentespresentes.Porlo tanto,laarquitecturagarantizadisponibilidadde cinconueves si se tienen tres agentes redundantes cada uno con una disponibilidaddealmenos98%(estoes3.6dasdetiempo muerto al ao) lo cual en trminos prcticos es bastante

14

RevistaAvancesenSistemaseInformtica,Vol.6No.1,Juniode2009,Medelln,ISSN16577663

deficienteparaunservidordedicadodadoquelosproveedores deestetipodeserviciosgarantizanporcontratounmnimode 99.9%, as con este ltimo factor bastaran dos agentes redundantesparaalcanzar cinconueves dedisponibilidad.

VI I . C O NC L USI O NE S

En este artculo se ha presentado una arquitectura que permite ofrecer servicios de telefona IP sobre Internet utilizando el protocolo SIP aadiendo a la infraestructura capacidadesdedistribucindecargaybrindandoescalabilidad deunaformasencillapara permitirmayorcapacidadyalta disponibilidaddelservicio. Al segmentar el problema en tres grandes frentes la infraestructuraresultantesevuelvemstoleranteafallosenel momentodeladesconexindeunoovariosnodosdelaredya quelosclientesSIPtienenaccesoininterrumpidoaalgunode losagentesredundantesgraciasaqueseaplicanlastcnicas DNSSRVRRparaprotocoloSIP.Lainformacinpropiadel servicio est disponible y actualizada en todas las bases de datosdebidoalesquemaescalablederplicasplanteado.Enel evento que alguno de los proveedores de terminacin en la PSTNpresentefallos,loscualesnosepuedencontrolardesde elpuntodevistadelainfraestructuradelITSP,elsistemaest encapacidaddeencaminarlallamadautilizandolosalgoritmos deredundanciadeproveedoresdescritos. Seconcluyefinalmentequeintroduciendoestosdesarrollos enlainfraestructuradeunproveedordeserviciosdetelefona IP (ITSP) este puede mejorar la capacidad de acceso, la escalabilidad,latoleranciaafallos,losporcentajesdeterminacin dellamadasyporlotantolaadopcindeestetipodetelefona comonaturalsustitutotecnolgicodelatelefonatradicional porconmutacindecircuitos.

Science. San Diego, CA. [7] Singh, K. and Schulzrinne, H., 2006. Failover, load sharing and server architecture in sip telephony, Department of Computer Science, Columbia University, New York. [8]Gulbrandsen,A.,Vixie,P.andEsibov,L.,2000.ADNSRRforspecifying the location of services (DNS SRV). Request for Comments 2782. ftp://ftp.ietf.org/rfc/rfc2782.txt. [9] Schulzrinne, H. and Rosenberg, J., 2002. Session initiation protocol (sip): Locating sip servers. Request for Comments 3263. ftp:// ftp.ietf.org/rfc/rfc3263.txt. [10]MySQL, 2009. Open Source SQL server, http://www.mysql.com. [11] Singh, K. and Schulzrinne, H., 2004. Failover and load sharing in sip telephony. Reporte Tcnico. CUCS01104, Columbia University, Computer Science Department, New York, NY, USA. [12] Schulzrinne, H., Casner, S., Frederick, R. and Jacobson V., 1889. RTP:A Transport Protocol for RealTimeApplications. Request for Comments 1889. ftp://ftp.ietf.org/rfc/rfc1889.txt.

An d r s P a r r a L on d o o Ingeniero Electrnico de la Universidad Autnoma de Occidente, Cali, Colombia (2004). Estudiante del Programa de Maestra en Ingeniera con nfasis en Electrnica en la Universidad del Valle, Cali, Colombia. Es miembro del grupo de investigacin en sistemas de telecomunicaciones de la Universidad delValle (SISTELUV). Actualmente se desempea como Gerente de Telefona y Telecomunicaciones de Ipsofactum S.A E.S.P. y es jefe de desarrollo de la infraestructura deVoIP de estacompaa. Susreas de intersson:Telefona IP, compatibilidad de sistemas telefnicos NGN con plataformas SS7 y sistemas distribuidos aplicados a la prestacin de servicios de VoIP. Fabio G. Guer r er o Ingeniero en electrnica y telecomunicaciones de la Universidad del Cauca, Popayn, Colombia (1992). M.Sc. Real Time Electronic Systems, Bradford University, United Kingdom (1995). Actualmente se desempea como profesor asistente de la Escuela de Ingeniera Elctrica y Electrnica de la Universidad del Valle (Cali, Colombia) en el rea de Telecomunicaciones. Coordinador del grupo de investigacin en sistemas de telecomunicaciones de la Universidad del Valle (SISTELUV). Sus reas de inters son: redes de prxima generacin, sistemas de comunicaciones mviles y comunicacin digital.

REFERENCIAS [1] Cisco, 2000. Highavailability solutions for sip enabled voiceoverip networks. White Paper. [2] Knight, S.,Weaver, D.,Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M. and Lindem, A., 1998. Virtual router redundancy protocol. Request for Comments 2338. ftp://ftp.ietf.org/ rfc/rfc2 338.txt. [3] Ohlmeier, N., 2003. Design and implementation of a high availability sip server architecture. Diplomarbeit, Technische Universitt Berlin, Berlin. [4] Rosenberg, J., Schulzrine, H., Camarillo, G., Johnston,A., Peterson, J., Sparks, R., Handley, M. and Schooler, E., 2002. Sip: Session initiation protocol. Request for Comments 3261, Junio 2002. ftp:// ftp.ietf.org/rfc/rfc3261.txt. [5]Singh, K. and Schulzrinne, H., 2004. Peertopeer internet telephony using sip. Department of Computer Science, Columbia University, New York. [6] Stoica, I., Morris, R., Karger, D., Frans Kaashoek, M. and Balakrishnan, H., 2001. Chord: A Scalable Peertopeer Lookup Service for Internet Applications. MIT Laboratory for Computer