Encaminhamento via SIP de Chamadas E.164 no operação e migração

Transcrição

1 Encaminhament via SIP de Chamadas E.14 n fne@rnp: peraçã e migraçã Paul Henrique de Aguiar Rdrigues Març de 200 V.0 Este relatóri apresenta a arquitetura para suprte a encaminhament via SIP de chamadas E.14 via SIP, bem cm define a peraçã e cenáris de migraçã para nv ambiente. RNP/RE/0204

2 Sumári 1. Mtivaçã para a migraçã para SIP A nva arquitetura centrada em SIP Princípis d Encaminhament Nacinal Encaminhament para uma instituiçã que pere apenas cm DSER Encaminhament para uma instituiçã que pere apenas cm DGK Encaminhament para uma instituiçã que pere cm DSER e DGK Migraçã para a nva arquitetura Vantagens da peraçã cm SIP para serviç fne@rnp...1. Pactes para upgrade de versã e migraçã para a nva arquitetura Exempls de fluxs De cliente SIP para cliente SIP, instituições n DSER De cliente SIP em instituiçã n DSER para instituiçã n DGK De cliente SIP de instituiçã n DGK para instituiçã n DGK...21 Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 2

3 1. Mtivaçã para a migraçã para SIP O serviç fne@rnp peru, desde a sua criaçã até final de 200 cm encaminhament de chamadas a nível nacinal pel H.2, fazend us d DGKRNP. Uma instituiçã que fizesse parte d serviç tinha que perar um gatekeeper H.2 (nrmalmente usand sftware livre GnuGK) para encaminhament e recebiment de chamadas, ainda que a sua base de usuáris fsse SIP. A arquitetura aberta suprtada e recmendada pel serviç fne@rnp na épca é mstrada na igura 1. igura1 Ambiente H.2/SIP para serviç fne@rnp até final de 200 As ambientes de sftware abert utilizads na arquitetura da igura 1 eram s seguintes: H.2: Gatekeeper GnuGK SIP: prxy SIP OpenSER, Mediaprxy GW de vz e GW H.2/SIP: Asterisk Banc de dads SQL: PsgreSQL Autenticaçã Radius: reeradius Diretóri LDAP: OpenLDAP Na arquitetura da igura 1, gateway de vz que se cnectava a PBX perava cm H.2, recebend e enviand as chamadas nas quais havia a participaçã d PBX via H.2. Assim, chamadas riginadas de utras instituições e destinadas a PBX da instituiçã lcal (pdend eventualmente ser um destin na RTC d códig de área lcal) eram encaminhadas pel DGK Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã.

4 usand a sinalizaçã H.2. Cas destin fsse um cliente registrad n prxy SIP institucinal, a chamada teria que passar pel Asterisk lcal, que funcinava cm gateway H.2/SIP. O Asterisk cm gateway H.2/SIP fi avaliad em terms de desempenh e mstru instabilidade n canal h2 quand númer de chamadas excedeu. O atras inserid pel gateway nas cndições de teste fi da rdem de 1 ms, sem cnversã de cdecs. Cm cnversã de cdecs, atras tendeu a pirar. O Asterisk lcal estava send utilizad cm canal h2, pr este canal permitir crrelacinar s CDRs d lad SIP cm s CDRs d lad H.2. A alternativa a canal h2 seria canal h2, mas este últim precisaria de ampla mdificaçã n códig para pssibilitar a crrelaçã entre s dis ambientes, essencial para a geraçã de CDRs cnslidads. As versões mais recentes d Asterisk sã 1.4.x. ram testadas as versões e Nessas versões, canal h2 nã é mais suprtad, além de ser um desenvlviment de terceirs. A alternativa seria us d nv canal h2 nativ, presente nas versões mais atuais. Tdavia, este canal nã funcinu crretamente nestas versões testadas. Pels fatres expsts, as versões que cntinuam a ser utilizadas n Asterisk, quand necessári suprte a H.2, sã as versões 1.2.x cm us d h2, cm s incnvenientes de atras e instabilidade já mencinads. Quand n cenári da igura 1, dis clientes SIP de diferentes instituições estabelecem uma chamada, essa chamada passa pr dis gateways H.2/SIP, que acrescenta mais de 120 ms de atras adicinal, prejudicand a interatividade, e, pssivelmente, cmprmetend a qualidade da ligaçã fim a fim. Quand um cliente SIP de uma instituiçã tem sua chamada encaminhada para PBX de utra instituiçã, a chamada passa também pr dis gateways, um gateway H.2/SIP (d lad d riginadr da chamada) e pr um gateway H.2/E1 d lad d destinatári da chamada. Cabe bservar que us d Asterisk cm gateway de vz smente cm SIP nã apresenta quaisquer ds prblemas relacinads a H.2. O SIP n Asterisk nas versões mais atuais é estável, rbust e testad cm atrass extremamente baixs (11 ms) cm 0 ligações simultâneas. Testes de terceirs demnstram que canal SIP d Asterisk suprta facilmente mais de 120 ligações simultâneas, sem um limite clar. Cm a mairia das instituições está implantand internamente apenas SIP, a tendência será de que se tenha a mairia das chamadas send riginadas em SIP e destinadas também a clientes SIP, principalmente se s gateways de vz institucinais perarem cm SIP. 2. A nva arquitetura centrada em SIP Visand atender a prcess evlutiv d serviç fne@rnp em direçã a SIP, serviç fne@rnp migru para a nva estrutura mstrada na igura 2. Na igura 2, bserva-se a inclusã d DSER (cm us ENUM e DNS privad) e d gateway H.2/SIP Asterisk n ambiente nacinal, além d já existente DGK. As setas pntilhadas em verde indicam as interações de sinalizaçã SIP entre s váris equipaments. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 4

5 4 PQRS G H I P Q R S D E M N O W X Y Z 0 # C I SC O I P P HO N E 02 SE R I ES 4 PQRS G H I P Q R S D E M N O W X Y Z 0 # C I SC O I P PH O N E 02 SE RI E S Cm pde ser bservad na igura 2, um prxy SIP interage cm DSER e cm Asterisk nacinal, bem cm cm s utrs prxies SIP, que façam parte d serviç. Tds esses elements sã parceirs ( peers ) u vizinhs e pdem estabelecer sinalizaçã direta entre si. A UNÇÃO DO DSER Na arquitetura da igura 2, DSER pera cm prxy de sinalizaçã para chamadas riginadas ds prxies SIP e d gateway H.2/SIP Nacinal. Sempre que DSER recebe um INVITE riund de um dispsitiv cnfiável, ele cnsulta DNS privad cm ENUM para descbrir s prxies u gateways que pdem receber a chamada. D SER D N S N APTR SLO N Y vizinhs prefixs SLO N Y vizinhs prefixs Prxy SIP O penser G ateway H.2 2/SIP G atew ay H.2 2/SIP G atew ay H.2 2/SIP Prxy SIP O penser Cliente A Cliente B D N S SRV G atew ay VIP/R R TC D G K G atew ay VIP/R R TC D N S SRV PABX G atekeeper G atekeeper PABX Instituiçã A Instituiçã B igura 2 Ambiente nacinal para encaminhament de chamadas via SIP para serviç fne@rnp Na ambiente nacinal, existe uma base de dads nde s prefixs e códigs de áreas cmpletads pelas instituições sã anunciads. Estes prefixs e códigs de área se referem as númers VIP, d PBX, linhas privadas u prefixs da telefnia pública. Uma instituiçã pde anunciar prefixs em mais de um códig de área, send uma decisã interna da própria instituiçã que prefixs sã u nã anunciads. Tdavia, a se anunciar um determinad prefix u grup de prefixs, a instituiçã tem que se cmprmeter a cmpletar as chamadas destinadas a estes prefixs. Tds s anúncis n ambiente nacinal sã guardads em um banc de dads mestre, que armazena também tdas as características peracinais das instituições. Para maires infrmações sbre as características armazenadas, favr cnsultar Dcumentaçã Técnica fne@rnp: Hmlgaçã de instituições d fne@rnp cm encaminhament nacinal via SIP. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 5

6 PRIORIDADE PARA ENCAMINHAMENTO DE CHAMADAS Em grandes centrs, existe a tendência de a RNP perar seus própris gateways cm a rede de telefnia pública, garantind diretamente a qualidade d serviç fne@rnp. Embra nestes centrs pssam existir instituições que também cmpletem chamadas para a rede pública de telefnia, estas instituições nrmalmente só deveriam receber chamadas d ambiente nacinal em segunda priridade, send s gateways da RNP usads em primeira instância. Em utrs centrs em que a RNP nã dispõe de gateway de presença, as chamadas para a rede de telefnia pública sã cmpletadas pelas próprias instituições lcais que fazem parte d serviç, se assim desejarem. Mesm nestes cass, algumas instituições pdem ter mair e melhr capacidade para cmpletar as chamadas, send interessante que as chamadas sejam encaminhadas de frma priritária. Para atender a pririzaçã, s prefixs anunciads na base de dads nacinal sã acmpanhads de um valr inteir psitiv, send 1 mais priritári. Nrmalmente, a priridade 1 está assciada à RNP. Quand uma instituiçã tem que encaminhar uma chamada destinada a utr códig de área, uma primitiva INVITE (d SIP) é enviada pel prxy de rigem a DSER. Após receber INVITE, DSER retrna um REDIRECT para riginadr, indicand s pssíveis prxies de destin, cm valr de priridade assciad. As tentativas de cmpletar a chamada serã feitas de frma seqüencial, seguind a rdem de priridade. Quand dis u mais destins estiverem relacinadas numa mesma priridade, eles serã acinads em paralel e primeir a cnfirmar receberá a chamada. Esse papel centralizad d DSER pde facilitar, n futur, us de esquemas de balanceament de chamadas mais sfisticads, se necessári. Pdem ser utilizadas variações de métrica que levam em cnta utrs fatres cm priridade, cust, cupaçã ds gateways e duraçã de chamadas externas já cmpletadas pr uma instituiçã num determinad períd. Essa versatilidade pssibilitada pel balanceament centralizad de chamadas depende apenas da manutençã n DSER de infrmações atualizadas das instituições. Prcediments já estã implementads ns gateways Asterisk d ambiente fne@rnp para que, sempre que uma chamada fr estabelecida u cmpletada, a métrica que relacina a capacidade d gateway e s númers de chamadas internas e externas em andament seja cmputada em temp real, através de scripts AGI. O DSER pera cm prxy de sinalizaçã, tant para as chamadas encaminhadas pels prxies SIP cm para as chamadas encaminhadas pel gateway H.2/SIP nacinal. Assim, a receber um INVITE vind d gateway H.2/SIP, DSER retrna REDIRECT. Imprtante bservar que canal SIP d gateway Asterisk nã implementa a tentativa de chamar s pssíveis destins seqüencialmente e/u paralelamente, efetuand a chamada apenas para a primeira pçã. Chamadas internacinais sã realizadas através de um Prxy SIP u através de Prxy H.2 cnfigurads para receber e encaminhar chamadas SIP u H.2 externas a serviç fne@rnp. O Prxy SIP cnsulta um banc de dads para identificar qual tip de tratament deve ser dad para as chamadas riundas da rede externa. Se a rede externa nã pssuir um cnvêni de serviç cm a RNP, entã as chamadas smente serã cmpletadas para númers interns a serviç fne@rnp, blqueand cmpletament das chamadas para a rede pública de telefnia. O tráfeg vind de redes descnhecidas será aceit n serviç fne@rnp, prém sfrerá a mesma plítica de tráfeg de rede sem cnvêni. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã.

7 N Prxy H.2, td tráfeg recebid de redes cnhecidas cnveniadas u nã terã permissã apenas para destins interns a serviç fne@rnp. Devid a dificuldades em desenvlver uma prgramaçã similar a implementada n Prxy SIP. O PAPEL DO DGK H.2 Na nva arquitetura, DGK pera cm prxy de sinalizaçã H.225 e H.245, send cnfigurad cm parceir d gatekeeper institucinal cas a instituiçã ainda pere cm DGK para encaminhament nacinal. A razã de DGK perar cm prxy de sinalizaçã é permitir que as instituições pssam fazer us d GnuGK 2.2.X, que apenas admite chamadas riundas de parceirs. Assim, um GnuGK 2.2.X, perand cm GK de uma instituiçã, terá apenas DGK e gateway H.2/SIP lcal cm parceirs. Nã será necessári que tds s utrs GKs d serviç fne@rnp sejam cnfigurads cm pares d GK da instituiçã. Essa peraçã facilita a escalabilidade e permite que as instituições façam us das versões mais recentes d GnuGK, que pssuem atualizações de segurança e funcinalidades imprtantes para ambiente H.2. A TABELA DE VIZINHOS O banc de dads na RNP está rganizad em tabelas mestres que pdem ser replicadas e suas cópias mantidas sincrnizadas. A tabela de vizinhs cupa um papel fundamental na peraçã d serviç. Essa tabela é mantida pela RNP e a replicaçã é feita cm us d sftware SLONY. Tda atualizaçã da tabela mestre, cm a inserçã de uma nva instituiçã n serviç fne@rnp u alteraçã de instituiçã já peracinal, é repassada para as cópias nas instituições. Em cada instituiçã, a receber uma chamada (primitiva INVITE), Prxy SIP acessa a tabela de vizinhs para verificar se a chamada é riginada de alguma instituiçã d serviç fne@rnp. A tabela de vizinhs cntém as assciações de um prxy SIP cm s prefixs e linhas privadas pels quais ele respnde. Algumas utras infrmações pertinentes, cm s endereçs IPs ds prxies, sã também mantidas nessa tabela. A tabela de vizinhs é cnsultada pel prxy SIP para validar s INVITES que chegam de instituições d serviç fne@rnp e para descbrir se s destins de chamadas sã c-lcalizads n mesm códig de área. Quand destin é c-lcalizad, a chamada é enviada diretamente a prxy de destin, sem us d DSER. A tabela de vizinhs é também cnsultada na cnslidaçã de CDRs, quand s IPs ds prxies e prefixs alcads permitem identificar a rigem e destin de uma chamada, pssibilitand preencher crretamente s camps d CDR cnslidad respectiv. Para a sinalizaçã SIP, a intrduçã da tabela de vizinhs trna cmpletamente transparente a inserçã de uma nva instituiçã n serviç quand já existem utras instituições já perand n mesm códig de área da nva instituiçã (chamadas c-lcalizadas). A tabela de vizinhs tem também um papel fundamental na atualizaçã de ambiente e na instalaçã inicial de uma nva instituiçã. Para maires infrmações, cnsulte a dcumentaçã sbre a hmlgaçã e a recnfiguraçã de instituições n serviç fne@rnp. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã.

8 . Princípis d Encaminhament Nacinal Embra a preferência atual seja pela peraçã cmpleta cm SIP, para permitir flexibilidade e cnvívi cm instituições que ainda peram cm H.2, há a necessidade de manter encaminhament ns dis padrões. Cm as instituições pdem suprtar internamente tant clientes H.2 cm SIP, é necessári definir uma regra de encaminhament que evite penalizar a qualidade das ligações, independentemente da frma de encaminhament nacinal esclhida e da rigem e destin das chamadas. As diretivas de peraçã d serviç estã definidas abaix: PRIMEIRA DIRETIVA BÁSICA: Uma instituiçã pde ter seus prefixs anunciads smente n DSER (instituiçã pera apenas cm encaminhament nacinal via SIP), smente n DGK (instituiçã pera apenas cm encaminhament nacinal via H.2), u em ambs (instituiçã pera cm ambs s encaminhaments). SEGUNDA DIRETIVA BÁSICA: Uma chamada deve permanecer num mesm ambiente de sinalizaçã máxim pssível de passs, minimizand us de gateways. Pr exempl, se um cliente H.2 de uma instituiçã que pera tant cm DSER cm cm DGK realiza uma chamada, esta chamada deverá ser enviada para DGK, evitand passar pel gateway H.2/SIP lcal. As seguintes situações pderã crrer: Se destin fr um cliente H.2 de uma instituiçã anunciada n DGK, a chamada ficará apenas n mund H.2 e nã cruzará nenhum gateway H.2/SIP. Se destin fr um cliente H.2 de uma instituiçã anunciada apenas n DSER, a chamada seguirá pel gateway H.2/SIP nacinal e ainda cruzará gateway H.2/SIP n destin, passand pr dis gateways. Essa situaçã nã é desejável, mas crre prque a instituiçã destin tem clientes H.2 e nã usa DGK. Desde que uma instituiçã tenha muits clientes H.2, será cnveniente que ela pere também cm DGK. Se destin fr um cliente SIP de uma instituiçã anunciada n DGK, a chamada será entregue n destin via H.2 e gateway H.2/SIP lcal entregará a SIP. A chamada passará apenas pr um gateway H.2/SIP. Se destin fr um cliente SIP de uma instituiçã anunciada apenas n DSER, a chamada seguirá pel gateway H.2/SIP nacinal e chegará a mund SIP passand apenas pr um gateway. Situaçã semelhante crrerá se a chamada fr gerada a partir de um cliente SIP. Nesse cas, a chamada será enviada para DSER, que a manterá n ambiente SIP, se prefix destin estiver registrad ali, u seguirá para gateway H.2/SIP nacinal, cas cntrári. Nã há, a princípi, cm saber se cliente de destin da chamada estará perand cm H.2 u cm SIP. A instituiçã destin pde ter clientes que se registram ns dis ambientes. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 8

9 Cas a chamada seja destinada a PBX, gateway de vz da instituiçã destin também pde estar perand apenas cm uma das sinalizações. Tdavia, pr prblemas de desempenh d Asterisk cm gateway H.2/SIP, recmenda-se que gateway de vz pere pel mens cm SIP. Evidentemente, uma instituiçã que pere cm s dis ambientes, H.2 e SIP, pderá ter seu gateway de vz cnectad tant a prxy SIP cm a gatekeeper H.2, evitand que as chamadas destinadas a PBX passem pel gateway H.2/SIP em qualquer circunstância. Um gateway H.2/SIP só deverá participar de uma chamada quand a rigem e destin da chamada estiverem em sinalizações pstas..1. Encaminhament para uma instituiçã que pere apenas cm DSER Uma instituiçã que tenha seus prefixs smente anunciads n DSER estará perand cm encaminhament nacinal via SIP. Assim, se chamadas frem riginadas n ambiente H.2 lcal, elas deverã ser encaminhadas a prxy SIP institucinal (nrmalmente OpenSER) via gateway H.2/SIP lcal. O OpenSER fará tratament da chamada, decidind se é destinada a PBX (send repassada a gateway de vz), se destinada à cliente IP lcal, se destinada a uma instituiçã clcalizada u se destinada a utr códig de área. Se a chamada fr destinada a uma instituiçã c-lcalizada, a tabela de vizinhs indicará prxy SIP de destin. Nesse cas, a chamada será repassada diretamente a prxy SIP de destin, sem necessidade de cnsulta a DSER. Prcura-se, cm esse prcediment, executar rapidamente um encaminhament de chamada para destins em área gegráfica próxima. Cas uma chamada fr destinada a um prefix que smente uma instituiçã esteja habilitada a cmpletá-la, a chamada será repassada a Prxy SIP da instituiçã diretamente, similar a encaminhament para uma instituiçã c-lcalizada. Se a chamada fr destinada a utr códig de área e exista mais de uma instituiçã habilitada a cmpletá-la, a chamada será encaminhada a DSER, similar a que se faz n ambiente H.2 cm envi de sinalizaçã RAS a DGK. Caberá a DSER identificar s pssíveis prxies de destin cm cnsulta via ENUM a DNS privad. Se a cnsulta retrnar mais de uma pçã de prxy de destin, um REDIRECT será retrnad a prxy remetente, identificand s prxies de destin e a priridade de cada um. Os destins sã cnsultads seqüencialmente em rdem de priridade, send que destins de igual priridade sã cnsultads em paralel, recebend a chamada destin que enviar a aceitaçã primeir a prxy de rigem. Se a cnsulta à tabela de vizinhs retrnar apenas um prxy de destin, entã a chamada será encaminhada diretamente para esse prxy. Cas nã seja encntrad nenhum destin pssível na base lcal da instituiçã que realiza a chamada, a mesma será repassada a DSER. Cas destin nã seja alcançável pel serviç (inexistência de anúnci n banc de dads mestre), a chamada será cancelada. Na nva arquitetura, smente sã repassadas a gateway H.2/SIP nacinal as chamadas riginadas n SIP cuj destin pde ser cmpletad pel ambiente H.2, evitand repasse de chamadas cm destin inalcançável. Cnvém aqui salientar que s destins H.2 externs a serviç fne@rnp estã send também anunciads n banc mestre. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã.

10 PROCESSAMENTO DE CHAMADAS ORIGINADAS DO GATEWAY DE VOZ (ORIGEM NO SISTEMA TELEÔNICO: PBX OU EM OPERADORA DIRETAMENTE CONECTADA AO GATEWAY DE VOZ) Se a instituiçã pssuir clientes tant SIP cm H.2, indicand que tems um gateway H.2/SIP e um GK lcal, gateway de vz pderia estar perand tant cm SIP cm cm H.2. Cas gateway de vz estivesse perand cm H.2, esta cnectividade permitiria que chamadas de clientes H.2 fssem encaminhadas a PBX sem passar pel gateway H.2/SIP lcal, que reduziria atras e cntribuiria para a qualidade dessas ligações. Tdavia, a peraçã ds canais H.2 d Asterisk pssui restrições e, pr questões de estabilidade, cnfiabilidade e dispnibilidade, recmenda-se a peraçã preferencial d gateway de vz Asterisk apenas cm SIP. Supnd gateway de vz registrad ns dis ambientes, quand uma chamada vinda d PBX fr recebida pel gateway de vz, este a analisará e recmenda-se que tme as seguintes decisões: Se a chamada fr destinada a um númer de telefne IP da própria instituiçã, númer pde estar registrad, usand um cliente SIP u H.2. Supnd que us preferencial na instituiçã seja SIP (afinal a instituiçã pera apenas cm DSER), gateway de vz deverá enviar pedid de estabeleciment da chamada inicialmente a SIP. Se destin nã estiver registrad n SIP, deverá ser retrnad um err e gateway de vz deverá enviar pedid de estabeleciment de chamada a GK. Se destin estiver de fat registrad cm um cliente H.2, a chamada será cmpletada, cas cntrári, telefne IP nã está registrad, e a chamada será cancelada. Se destin da chamada fr utra instituiçã, gateway de vz deverá encaminhar a chamada a prxy SIP, que a prcessará nrmalmente, cm já indicad acima. Se gateway de vz estiver apenas registrad n SIP, cm esperad na arquitetura de referência d serviç fazend us d sftware Asterisk, cmprtament padrã é encaminhar via gateway H.2/SIP para GK cas destin lcal nã esteja registrad n SIP. Cas também nã haja registr n GK, cmprtament padrã é sempre repassar a gateway H.2/SIP quand destin nã fr encntrad n H.2. O retrn da chamada a prxy SIP será detectad cm um err (destin inexistente) e a chamada será cancelada. TRÁEGO SIP DE ORIGEM EXTERNA AO SERVIÇO ONE@RNP INVITES de rigem descnhecida recebids a rigem nã está na tabela de internacinal e nã faz parte d serviç fne@rnp devem ser encaminhads cm a inserçã de 1 de marcaçã de chamada de rigem externa se destinads a PBX lcal, a númers IP u a linhas privadas da própria instituiçã. Se destin nã fr lcal à instituiçã, entã a chamada deve ser cancelada, ainda que destinada à utra instituiçã d serviç fne@rnp. A cnfiguraçã d prxy SIP lcal na instituiçã deverá garantir este cmprtament. Embra nã haja impediment técnic para que um INVITE de rigem externa e destinad a utra instituiçã d serviç fne@rnp seja prcessad cm um INVITE qualquer, ptu-se pr nã permitir que uma instituiçã qualquer d serviç pssa ser prta de entrada de tráfeg VIP para utrs destins. A trca de tráfeg SIP cm utras redes deve ser realizada preferencialmente através d prxy SIP cnfigurad para recebiment exclusiv de chamadas SIP externas (nacinais u internacinais). Este prxy pde dar tratament diferenciad a cada rede cm base em SLA (acrd de serviç). Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 10

11 .2. Encaminhament para uma instituiçã que pere apenas cm DGK Uma instituiçã que tenha seus prefixs anunciads smente n DGK estará perand cm encaminhament nacinal via H.2. Esse é cas de instituições mais antigas que ainda nã sfreram a migraçã para encaminhament SIP. O prcessament das chamadas neste cenári é sempre feit pel gatekeeper lcal, send utilizad sftware GnuGK na arquitetura de referência. Se chamadas frem riginadas n ambiente SIP, elas deverã ser encaminhadas a gatekeeper institucinal (nrmalmente GnuGK) via gateway H.2/SIP lcal. O GnuGK fará tratament da chamada, decidind se é destinada a PBX (send repassada a gateway de vz), se destinada a cliente IP lcal, se destinada a uma instituiçã clcalizada u se destinada a utr códig de área. Se a instituiçã pssuir clientes SIP e H.2, indicand que tems um gateway H.2/SIP e um prxy SIP lcais, gateway de vz pderá estar registrad tant n SIP cm n H.2. O fat d gateway de vz estar registrad n SIP permitirá que chamadas de clientes SIP sejam encaminhadas a PBX sem passar pel gateway H.2/SIP lcal, que reduz atras e cntribui para a qualidade dessas ligações. Ainda neste cas, cnsiderand que a peraçã ds canais H.2 d Asterisk pssuem restrições, pr questões de estabilidade, cnfiabilidade e dispnibilidade, recmenda-se a peraçã d gateway de vz Asterisk apenas cm SIP. Entretant, uma instituiçã pde ter um gateway de vz diferente d Asterisk, sem ter as restrições deste. Supnd gateway de vz registrad ns dis ambientes, quand uma chamada vinda d PBX fr recebida pel gateway de vz, este a analisará e deverá tmar as seguintes decisões: Se a chamada fr destinada a um númer de telefne IP da própria instituiçã, númer pde estar registrad, usand um cliente SIP u H.2. Supnd que us preferencial na instituiçã seja H.2 (afinal, a instituiçã pera apenas cm DGK), gateway de vz deverá enviar pedid de estabeleciment da chamada inicialmente a H.2. Se destin nã estiver registrad n H.2, deverá ser retrnad um err e gateway de vz deverá enviar pedid de estabeleciment de chamada a prxy SIP. Se destin estiver de fat registrad cm um cliente SIP, a chamada será cmpletada, cas cntrári, telefne IP nã está registrad e a chamada será cancelada. Se destin da chamada fr utra instituiçã, gateway de vz encaminhará a chamada a GK, que a encaminhará a DGK. Se gateway de vz estiver apenas registrad n H.2 (cm crre em muitas instituições que peram smente cm clientes H.2), cmprtament padrã é encaminhar via gateway H.2/SIP para SIP cas destin lcal nã esteja registrad n H.2. Cas também nã haja registr n SIP, cm a chamada fi riginada d lad H.2, será detectad um err (destin inexistente) e a chamada será cancelada. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 11

12 .. Encaminhament para uma instituiçã que pere cm DSER e DGK Enquant serviç fne@rnp mantiver a peraçã de encaminhament nacinal tant cm SIP cm cm H.2, uma instituiçã que tenha clientes nas duas sinalizações pde ptar pr manter encaminhament nacinal também pelas duas sinalizações. Nessa situaçã, s prefixs da instituiçã estarã send anunciads tant n DSER cm n DGK, permitind que chamadas riginadas d SIP sejam encaminhadas via SIP e chamadas riginadas n H.2 sejam encaminhadas via H.2. Recmenda-se para esta instituiçã que seu gateway de vz seja cnectad tant a prxy SIP cm a gatekeeper H.2, evitand que as chamadas destinadas a PBX tenham que passar pel gateway H.2/SIP lcal em qualquer circunstância. Supnd gateway de vz registrad ns dis ambientes, quand uma chamada vinda d PBX fr recebida pel gateway de vz, este a analisará e deverá tmar as seguintes decisões: Se a chamada fr destinada a um númer de telefne IP da própria instituiçã, númer pde estar registrad, usand um cliente SIP u H.2. Supnd que us preferencial na instituiçã seja SIP (H.2), gateway de vz deverá enviar pedid de estabeleciment da chamada inicialmente a SIP (H.2). Se destin nã estiver registrad n SIP (H.2), deverá ser retrnad um err e gateway de vz deverá enviar pedid de estabeleciment de chamada a GK (prxy SIP). Se destin estiver, de fat, registrad cm um cliente H.2 (SIP), a chamada será cmpletada, cas cntrári, telefne IP nã está registrad e a chamada será cancelada. Se destin da chamada fr utra instituiçã, gateway de vz encaminhará a chamada a prxy SIP (esclhid preferencialmente), que a prcessará nrmalmente. Se gateway de vz estiver apenas registrad n H.2 (cm crre cm a mairia das instituições atuais), entã cmprtament padrã é encaminhar via gateway H.2/SIP para SIP cas destin lcal nã esteja registrad n H.2. Cas também nã haja registr n SIP, cm a chamada fi riginada d lad H.2, será detectad um err (destin inexistente) e a chamada será cancelada. O blquei é sempre feit n lad SIP. Se gateway de vz estiver apenas registrad n SIP, entã cmprtament padrã é encaminhar via gateway H.2/SIP para GK cas destin lcal nã esteja registrad n SIP. Cas também nã haja registr n GK, cmprtament padrã é sempre repassar a gateway H.2/SIP quand destin nã fr encntrad n H.2. O retrn da chamada a prxy SIP será detectad cm um err (destin inexistente) e a chamada será cancelada. O blquei é sempre feit n lad SIP. 4. Migraçã para a nva arquitetura Cm encaminhament nacinal de chamadas E.14 via SIP e via H.2 send suprtads n serviç fne@rnp, uma instituiçã que pretenda apenas perar cm SIP pderá se desfazer d ambiente H.2 e usar a infra-estrutura nacinal para se cmunicar cm ambiente H.2. De igual Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 12

13 frma, se uma instituiçã que hje só pere cm H.2 quiser cntinuar apenas cm esse ambiente, ela pderá manter apenas a peraçã cm DGK. Tdavia, nesse cas, a cmunicaçã das utras instituições cm ela seguirá necessariamente pel gateway H.2/SIP nacinal e pderá ser afetada pels atrass intrduzids pr esses elements. Num prcess de migraçã de uma instituiçã atual para SIP, a instituiçã pde manter, em determinad mment, s dis encaminhaments sem qualquer prblema, suprtand s dis ambientes que estã dispníveis para seus usuáris. Recmenda-se, nesse cas, que gateway de vz passe a ser registrad ns dis ambientes para melhrar a qualidade das chamadas riginadas e destinadas a PBX da instituiçã se nã huver prblema cm gateway de vz. Se a instituiçã decidir ptar apenas pr SIP, desfazer anúnci de seus prefixs n DGK é a única tarefa de manutençã d serviç a ser feita. Cm s prefixs da instituiçã já estã anunciads n DSER, nada mais precisará ser feit. Os gatekeepers instalads atualmente utilizam GnuGK versã A nva arquitetura suprta transparentemente esta versã mais antiga d GK, mas é recmendad, pr questã de segurança, que haja a migraçã para GnuGK versã que fi testada e já hmlgada n nv ambiente. A arquitetura d serviç vem send cnstantemente atualizada cm nvas versões ds pactes de instalaçã, incrprand melhrias e nvas facilidades, cm é cas da funçã de mapeament de númers, bastante útil para a habilitaçã de telefnes IP cm numeraçã d PBX em substituiçã a ramais analógics cnvencinais. Nrmalmente, prcess de migraçã é semelhante a uma nva instalaçã, cm a atualizaçã de td ambiente. Instituições que tenham cnfigurações especiais cm integraçã cm diretóris crprativs LDAP u utras, devem prcurar analisar bem estas cnfigurações para sua adaptaçã a nv ambiente. O prcess de migraçã de uma instituiçã nã padrã é únic e quadr técnic da instituiçã deve sempre estar preparad para peraçã de recuperaçã em cas de falha d nv ambiente e necessidade de retrn a ambiente riginal. 5. Vantagens da peraçã cm SIP para serviç fne@rnp Será sintetizad a seguir alguns pnts extremamente favráveis à adçã preferencial de SIP tant pelas instituições cm pel encaminhament nacinal de chamadas E.14. D pnt de vista das instituições: O desempenh da arquitetura VIP institucinal cm a adçã de gateways de vz Asterisk cm sinalizaçã SIP traz s benefícis de estabilidade d sftware frente a grandes númers de chamadas ativas simultaneamente e ds atrass mínims envlvids; Para a sinalizaçã SIP, us da tabela de vizinhs n prxy SIP trna cmpletamente transparente a inserçã de utras instituições n serviç n mesm códig de área (clcalizadas). Nenhuma reprgramaçã é necessária. Para ambiente H.2, um nv cnjunt de regras de reescritas deve ser inserid para cntemplar s prefixs e linhas privadas anunciads para cada nva instituiçã c-lcalizada. Prcesss manuais pdem riginar errs e anúnci incrret de uma c-lcalizada pde levar a falha de prcessament da chamada u a cmpletament de chamadas para destin c-lcalizad Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 1

14 via rede pública de telefnia, nerand desnecessariamente s custs de telefnia. Cm algumas instituições pssuem um númer muit grande de linhas privadas, a cnfiguraçã crreta destas instituições cm c-lcalizadas dentr da arquitetura anterir é cmpletamente inviável; O us de SIP internamente se alinha cm as tendências maires d mercad em suprte a este prtcl; Extrema facilidade de prgramaçã assciada a mund SIP, trazend flexibilidade, simplicidade para invaçã e mair capacidade de integraçã a mund Web, que favrece apareciment de nvs serviçs e flexibilidade de gerência e cnfiguraçã; Os prduts aberts para mund SIP, cm s sftphnes, pssuem uma interface cm usuári mais elabrada e cm mair apel. Atualmente, a ferta de prduts SIP é muit mair que para H.2, favrecend preçs mais baixs; A estabilidade de sluções de PBX IP aliada à queda de preçs ds equipaments VIP favrece a migraçã de sluções de telefnia cnvencinal para a telefnia IP. D pnt de vista d serviç fne@rnp: O us de SIP n encaminhament de chamadas E.14, pelas facilidades de prgramaçã que ambiente SIP apresenta para estabeleciment e encaminhament de chamadas, usufrui de uma implementaçã simples de mecanisms de balanceament centralizad. A implementaçã de balanceament n mund H.2 nã seria facilmente realizada sem uma alteraçã prfunda d códig ds ambientes, que inviabiliza a sluçã; Cm a sinalizaçã SIP, prcess de entrada de c-lcalizadas é transparente cm us da tabela de vizinhs e crre de frma autmática, sem a necessidade de alteraçã u de inserçã manual de regras de reescrita. Alterações de cnfiguraçã manuais pdem deixar de ser feitas u pdem ser realizadas cm err. O anúnci incrret de uma c-lcalizada pde levar a cmpletament de chamadas para destin c-lcalizad via rede pública de telefnia, nerand desnecessariamente s custs de telefnia. Trabalhs de auditagem em H.2 têm que ser feits nã smente na nva instituiçã cm em tdas as c-lcalizadas smente. O nv encaminhament via SIP trará uma reduçã significativa da carga gerencial, técnica e administrativa gerada pel serviç fne@rnp; Cm a sinalizaçã SIP já fi cncebida para us nrmal de DNS e alias para s usuáris, além de incrprar facilidades para cnvivência cm NAT/irewalls, SIP pera em muitas situações em que H.2 falha, facilitand a gerência e cnfiguraçã d serviç; Cm a tabela de vizinhs é parte d ambiente SIP e mantida cmpletamente atualizada e cm as infrmações nesta tabela sã essenciais para a geraçã de CDRs cnslidads, us d SIP é uma garantia cmpleta de que prcess de geraçã de estatísticas será crret e precis. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 14

15 . Pactes para upgrade de versã e migraçã para a nva arquitetura Para que haja a migraçã para nvas versões de pactes de sftware e para a nva estrutura, fram criads pactes e scripts de instalaçã que facilitam enrmemente a atualizaçã/recnfiguraçã de uma instituiçã já peracinal u a ativaçã de uma nva instituiçã. Os pactes fram desenvlvids para a distribuiçã Linux Debian Etch 4.0. Um primeir bjetiv ds pactes é facilitar a atualizaçã d ambiente, que é feit de frma extremamente simples. Um segund bjetiv é us de Debian estável em tda a arquitetura recmendada pela RNP para peraçã n serviç fne@rnp cm sftware livre. A pçã pel Debian é uma questã de preferência d Labratóri VIP. Outr ambiente Linux pde ser utilizad desde que ambiente seja adaptad. Supõe-se que utras distribuições baseadas n Debian também suprtem s pactes d serviç. N prcess de instalaçã, é assumid que duas máquinas estã dispníveis smente cm Debian instalad. A estrutura a ser implantada segue a seguinte estrutura de serviçs: Máquina 1 hspedand OpenSER, Asterisk (GW H.2/SIP), GnuGK, MediaPrxy e Radius client.-ng. Máquina 2 hspedand Asterisk (GW PBX), PstgreSQL, Slny, Apache, reeradius, OpenLDAP e Slny. Os pactes atuais suprtam as seguintes versões de sftware: Ambiente nacinal penser pwlib-mimas_patch2 penh2-mimas_patch2 gnugk 2.2. pstgres 8.1 asterisk asterisk-h2-0.. asterisk-h2-0.5 sln bind..4 Ambiente da instituiçã Asterisk labvip (versã alterada pel LabVIP) Asterisk labvip (versã alterada pel LabVIP) Asterisk-h2 0..-labvip (versã alterada pel LabVIP) Asterisk-perl 0.10 reeradius 1.1.-labvip (versã alterada pel LabVIP) GnuGK 2.2. libmfcr libpri 1.4. libsupertne libunicall mediaprxy OpenLDAP 2..2 OpenSER ntls radiusclient-ng spandsp 0.0. Zaptel fejeca (ferramenta de gerência desenvlvida pel LabVIP) Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 15

16 Cnslida e Estatística 0.0. (sftwares utilizads nas estatísticas desenvlvids pel LabVIP) O script de cnslidaçã de CDR faz parte d pacte e rda na máquina 2. Para criaçã inicial de usuáris n LDAP, existe a ferramenta ejeca, que é dispnibilizada cm parte d pacte de instalaçã. i elabrad um script de instalaçã que cnsulta as infrmações frnecidas previamente pela instituiçã e que fram inseridas n banc de dads mestre. Sã utilizadas as seguintes premissas: Sempre será instalad ambiente SIP e encaminhament nacinal via SIP estará habilitad; O ambiente H.2 lcal é pcinal. Na definiçã, será especificad se este ambiente será instalad. A respsta deve ser sim cas a instituiçã queira suprtar clientes H.2. O fat de se ter H.2 instalad nã quer dizer que a instituiçã perará cm DGK; A decisã de perar também cm DGK é parte das infrmações acrdadas previamente cm a RNP. Obviamente, se uma instituiçã quiser perar cm DGK ela terá que ter suprte a ambiente H.2. Caberá à RNP anunciar as infrmações da instituiçã tant n DSER cm n DGK aprpriadamente. Cm a esclha ds encaminhaments já é preliminarmente definida cm a RNP, essa infrmaçã será usada de frma autmática na instalaçã ds pactes, a partir das infrmações da base da RNP. Para gateway de vz cnectad a ramais analógics, é assumid que será instalada pel mens uma placa 4xXO, send que serã definids, na cnfiguraçã, quais ramais perarã cm IVR intern (para us ds ramais d PBX) e quais trabalharã cm IVR extern (pdend receber chamadas externas). Os númers de ramais assciads a cada uma das prtas XO e s númers de grup fazem também parte das infrmações previamente acrdadas cm a RNP. Para um gateway de vz cnectad a uma placa E1, é supst que tems apenas uma placa e um tip de sinalizaçã (R2 u ISDN). Parte ds 0 canais dispníveis pde estar alcada a IVR intern e a utra parte a IVR extern. Esta é uma questã de acert de cnfiguraçã cm PBX. Os númers de grup (u ramal chave) ds IVRs sã também cnfiguráveis n PBX. Estas infrmações precisam cnstar da base de dads acrdada cm a RNP. Durante a execuçã d script de instalaçã, banc de dads da RNP que cntém as infrmações previamente acrdadas cm a instituiçã antes de sua entrada em serviç é cnsultad. O banc cntém tda a infrmaçã necessária para as cnfigurações de instalaçã, excet as infrmações de segurança, referentes a senhas lcais, que sã slicitadas pel script de instalaçã em temp real. A infrmaçã envlvida é referenciada a seguir: Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 1

17 Infrmações cnstantes d banc da RNP TABELA INSTITUIÇÕES Camp pk (integer) Identificaçã única para a instituiçã Camp nme (char) Sigla da instituiçã Camp ativ (blean) Infrma se a instituiçã está ativa Camp respnsavel (char) Nme d respnsavel da instituiçã Camp (char) d respnsável da instituiçã Camp ddd (char) Códig de área Camp dmini (char) REALM vip da instituiçã Camp encaminhament_sip (blean) Descreve se a instituiçã faz encaminhament SIP: True -> az SIP ; alse -> Nã faz SIP Camp encaminhament_h2 (blean) Descreve se a instituiçã faz encaminhament H.2: True -> az H.2 ; alse -> Nã faz H.2 Camp encaminhament_pstn (blean) Descreve se a instituiçã faz encaminhament H.2: True -> az encaminhament para a PSTN ; alse -> Nã faz encaminhament para a PSTN Camp h2_intern (blean) Descreve se instituiçã usa H.2 internamente True -> H.2 é usad internamente; alse -> H.2 nã é usad internamente Camp versã (integer) Descreve versã d sistema: 1 -> primeira versã ; 2 -> versã atutal Camp interface_pabx (char) Descreve qual interface utilizada para cnexã cm PABX R2, ISDN u XO TABELA EQUIPAMENTOS Camp id (integer) Identificaçã única para equipament Camp pk (integer) Identifica a que instituiçã este equipament crrespnde Camp ip (inet): Endereç IP d equipament Camp tip (integer [ 0 1 ] ) Identifica tip de equipament 1 para Prxy 0 para Camp descriçã (char) Cmentári sbre equipament TABELA PREIXOS Camp id (integer): Identificaçã única d prefix Camp pk (integer): Identifica a que instituiçã este prefix crrespnde Camp tip (integer [ ] ) Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 1

18 Identifica tip de prefix: 2 para Prefix da linha privada (Pdend ser númer inteir) 1 para Prefix d PABX (Institucinal) 0 para Prefix ip (fne@rnp) Camp ddd (char) DDD desta instituiçã Camp prefix (char) Prefix desta instituiçã (sem ddd) TABELA NUMERO_IVR Camp id (integer): Identificaçã única d prefix Camp pk (integer): Identifica a que instituiçã este prefix crrespnde Camp numer (char) Identifica tip de númer IVR: 2 para Prefix da linha privada (Pdend ser númer inteir) 1 para Prefix d PABX (Institucinal) 0 para Prefix ip (fne@rnp) Camp numer (char) Númer IVR desta instituiçã As infrmações d banc de dads da RNP sã imprescindíveis para a entrada em peraçã de uma instituiçã n serviç fne@rnp. As duas tabelas acima têm que ser preenchidas cm parte preliminar d prcess de entrada da nva instituiçã n serviç fne@rnp. Além diss, as infrmações sbre s ramais e númers de grup assciads às interfaces analógicas (XO) e digitais (E1 R2 u E1 ISDN) sã imprescindíveis para s prcesss de hmlgaçã e auditagem da RNP. Infrmaçã de segurança slicitada pel script de instalaçã Senha d LDAP Segred d servidr RADIUS Senha d usuári radius na base de dads Senha d usuári asterisk na base de dads Senha d usuári penser na base de dads Senha d usuári pstgres, administradr da base de dads Infrmaçã sbre s camps d LDAP existentes na máquina 1 das instituições uid cn userpasswrd mail alias carlicense emplyeetype callfrward respnsável credits-perid crédits ipaddress validade categria H2passwd Nme d usuári Caminh na árvre LDAP deste usuári Senha utilizada para um usuári se registrar n OPenSER deste usuári Telefne IP deste usuári Dcument de identificaçã d usuári Tip d usuári na instituiçã Númer para encaminhament de chamadas (nã implementad ainda) Nme de um respnsável da cnta Quantidade de crédits utilizads perídicamente n camp crédits Crédits para ser utilizads em ligações cm a PSTN Limitar IP que pde se autenticar (Nã implementad ainda) Validade da cnta d usuári Classificaçã d usuári utilizad para definir quantidade de crédits Senha para autenticaçã d usuári n GNUGK Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 18

19 4 PQRS G H I P Q R S DE M N O W X Y Z 0 # CISCO IP PHONE 02 SE RIE S 4 PQ RS GHI P Q R S 0 DE MN O W X Y Z # CISCO IP PHONE 02 SE RIE S 4 PQRS G H I P QR S D E M N O WX Y Z 0 # CIS CO IP PHONE 02 SE RIE S. Exempls de fluxs Ns exempls a seguir, as linhas pntilhadas representam caminh da sinalizaçã e as linhas cheias a rta da mídia de vz..1. De cliente SIP para cliente SIP, instituições n DSER Este é cenári típic de uma chamada entre dis clientes SIP de instituições que peram cm DSER. O riginadr da chamada é cliente A. O OpenSER riginadr repassará INVITE da chamada a DSER, que retrnará REDIRECT indicand prxy destin. Os canais de mídia sã entã estabelecids diretamente entre s clientes SIP, passand pels prxies de rigem e de destin que peram cm prxies de sinalizaçã. DSER DNS NAPTR SLONY pares prefixs mídia Prxy SIP OpenSER SLONY pares prefixs Prxy SIP OpenSER H.2/SIP H.2/SIP H.2/SIP Cliente A VIP/RTC Cliente B DNS SRV VIP/RTC DGK DNS SRV PABX Gatekeeper Gatekeeper Cliente B PABX Instituiçã A Instituiçã B igura Estabeleciment de chamadas entre prxies SIP via DSER Cas a chamada fsse, na realidade, destinada a PBX na instituiçã B, entã a mídia seguiria até Asterisk perand cm gateway de vz, que cmpletaria a chamada para PBX. Cm Asterisk pera cm atras bem baix, a chamada nã seria afetada em sua qualidade a passar pr este element adicinal. Pr utr lad, destin da chamada na instituiçã B pde ser um cliente H.2. Nesse cas, a chamada passará pel gateway H.2/SIP lcal. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 1

20 4 PQRS G H I P Q R S DE M N O W X Y Z 0 # CISCO IP PHONE 02 SE RIE S 4 PQR S GH I P Q R S D E M N O W X Y Z 0 # CISCO IP PHONE 02 SE RI ES 4 PQRS G H I P QR S D E M N O WX Y Z 0 # CIS CO IP PHONE 02 SE RIE S Se as duas instituições suprtam clientes ns dis tips de sinalizaçã, entã se espera que gateway de vz se registre ns dis ambientes. Em tds s cass, a chamada segue sempre encaminhada pr SIP..2. De cliente SIP em instituiçã n DSER para instituiçã n DGK Nesse cenári, a instituiçã A encaminha via SIP e a instituiçã B pera apenas cm DGK, nã suprtand encaminhament pr SIP e nã tend nenhum anúnci de seus prefixs n DSER. O riginadr da chamada é cliente A. DSER DNS NAPTR SLONY pares prefixs Prxy SIP OpenSER Prxy SIP OpenSER H.2/SIP H.2/SIP mídia H.2/SIP Cliente A VIP/RTC Cliente B DNS SRV VIP/RTC DGK DNS SRV PABX Gatekeeper Gatekeeper PABX Instituiçã A Instituiçã B igura 4 Estabeleciment de chamadas de SIP para H.2 via gateway H.2/SIP nacinal A chamada será encaminhada a DSER que, a nã encntrar anúnci de prefix da instituiçã B de destin, redirecina a chamada para gateway H.2/SIP nacinal e deste a DGK. Cm a instituiçã B pera apenas cm DGK, anúnci de seu prefix será encntrad e a chamada encaminhada a GnuGK de destin. N cas d destin da chamada na instituiçã B estar n SIP, a chamada terá que passar pel gateway H.2/SIP lcal e pel prxy SIP. Espera-se que gateway de vz na instituiçã B se cnecte tant a SIP quant a H.2. Assim, uma chamada destinada a PBX pde seguir d GnuGK diret a gateway de vz sem passar pr nenhum utr element. Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 20

21 4 PQRS GHI P Q R S DE MN O W X Y Z 0 # CISCO IP PHONE 02 SE RIE S 4 PQ RS GH I P Q R S 0 DE MN O W X Y Z # CISCO IP PHONE 02 SE RIES 4 PQRS G H I P QR S D E M N O W X Y Z 0 # CIS CO IP PHONE 02 SERIES.. De cliente SIP de instituiçã n DGK para instituiçã n DGK O cenári abaix mstra duas instituições que peram cm DGK apenas para encaminhament mas pssuem clientes tant em SIP cm em H.2. Este é um exempl d funcinament atual d serviç fne@rnp. O riginadr da chamada é cliente A. Observe que pir cas, em terms de númer de elements envlvids e de atrass, acntece para a chamada send riginada e destina a cliente SIP. Nesse cas, a chamada tem que ultrapassar dis gateways H.2/SIP. DSER DNS NAPTR Prxy SIP OpenSER Prxy SIP OpenSER H.2/SIP H.2/SIP H.2/SIP Cliente A VIP/RTC Cliente B DNS SRV VIP/RTC mídia DGK DNS SRV PABX Gatekeeper Gatekeeper Cliente B PABX Instituiçã A Instituiçã B igura 5 Estabeleciment de chamadas de SIP para H.2 via DGK Encaminhament via SIP de Chamadas E.14 em SIP n fne@rnp: peraçã e migraçã. 21