[AsteriskBrasil] RES: RES: RES: RES: Asterisk não detecta atendimento pela operadora

Ronaldo Toledo rtmorais em gmail.com
Quinta Junho 6 02:45:07 BRT 2013


Mike e Fernando.
Mais uma vez demorei para voltar aqui para contar o resultado das sugestões.
As dicas funcionaram muito bem para fazer com que o callfile direcionasse a
execução do callfile para dentro de
um determinado contexto no dialplan. O problema que encontrei é que ao
ligar para os mesmos números via telefone e via troncos SIP obtenho
comportamentos diferentes.  Na chamada direta via telefone eu recebo a
mensagem da operadora dizendo que o número não é válido. Ligando via
sipphone, via dois troncos diferentes, ouço o ring tocando na outra ponta
sem parar. O problema agora só será resolvido pelas operadoras dos meus
troncos.

Quero agradecer muito a vocês. Aprendi pra caramba. Nem fazia idéia da
existência da  tech Local (e olhem que já existia na  versão 1.4).

Abraços.
Ronaldo.




Em 25 de maio de 2013 14:42, Mike Tesliuk <mike em tesliuk.com> escreveu:

>  Deixe eu exemplificar como eu faria.
>
> Callfile:
>
> Channel: Local/s em disca
> Context: testeamd2
> extension: s
> priority: 1
> Set: NUMERO=31nnn
>
>
>
>
> extension:
>
> [disca]
> exten => s,1,Set(SIP_CODEC=gsm)
> exten => s,n,Set(SIP_CODEC_OUTBOUND=gsm)
> exten => s,n,Dial(SIP/qualita/${NUMERO},,tT)
> exten => s,n,Noop(Telefone chamado ${NUMERO})
> exten => s,n,Verbose(hangupcause = ${HANGUPCAUSE})
> exten => s,n,Verbose(causa =
> ${HASH(SIP_CAUSE,${CDR(/SIP/qualita/${NUMERO})})})
>
>
> [testeamd2]
> exten => s,1,Answer()
> exten => s,n,Wait(2)
> exten => s,n,PlayBack(/usr/local/projetoamd/teste)
> exten => s,n,Hangup()
>
>
>
>
>
> Eu nao testei estes parametros, apenas escrevi baseado no seu modelo e no
> que eu costumo fazer
>
>
>
> Em 25/05/13 04:19, Ronaldo Toledo escreveu:
>
>  Caros Fernando e Mike, demorei a postar porque não pude me debruçar
> novamente  no problema.
>  Alterei o sip.conf no [general], acrescentando
> use_q850_reason = yes
>
>
>  o call file criado
>
> Channel: SIP/Lucas
> Context: interno
> extension: s
> priority: 1
> waittime: 30
> Set: NUMERO=31nnnnnnnn
> Set: SIP_CODEC=gsm
> Set: SIP_CODEC_OUTBOUND=gsm
>
>  A definição do usuário Lucas
>
>  [Lucas]
> type=friend
> host=dynamic
> nat=yes
> username=1004
> callerid=1004
> context=interno
> canreinvite=no
> allow=gsm
>
>  o contexto [interno] no dialplan
>
>
>  [interno]
> exten => s,1,Noop(${NUMERO})
> exten => s,n,Set(number=${UMERO});
> exten => s,n,Dial(SIP/qualita/${NUMERO},,tT)
> exten => failed,1,Noop(${NUMERO})
> exten => failed,n,Set(NUMBER=${NUMERO})
> exten => failed,n,Set(SIP_CODEC=gsm)
> exten => failed,n,Set(SIP_CODEC_OUTBOUND=gsm)
> exten => failed,n,Goto(testeamd2,s,1)
>
>  O contexto testeamd2 contém em seu início
> [testeamd2]
> exten => s,1,Set(marca=0)
> exten => s,n,Set(SIP_CODEC=gsm)
> exten => s,n,Set(SIP_CODEC_OUTBOUND=gsm)
> exten => s,n,Dial(SIP/qualita/${NUMERO},,tT);
> exten => s,n,Noop(Telefone chamado ${NUMERO})
> exten => s,n,Verbose(hangupcause = ${HANGUPCAUSE})
> exten => s,n,Verbose(causa =
> ${HASH(SIP_CAUSE,${CDR(/SIP/qualita/${NUMERO})})})
> exten => s,n,Playback(/usr/local/projetoamd/teste)
>
>
>  Bem, aqui é que está o problema, imagino.   O sipphone Lucas existe no
> sip.conf mas não está registrado(porque não deve atender a ligação
> disparada pelo callfile). O propósito é mesmo provocar uma falha na chamada
> para que o Asterisk execute a extensão failed do contexto [interno] e
> execute o tão pretendido dial para os números que realmente nos interessam
> e analisar os códigos de erro sip resultantes para um report mais
> específico.
>
>  Mas o fato é que o Dial não acontece porque o Sip não consegue criar o
> canal, como mostram as mensagens abaixo. Ele entende que o codec que estou
> usando (nothing) não tem o correspondente na outra extremidade. Imagino que
> o nothing seja devido ao fato de a ligação via callfile não ter acontecido,
> e ela não pode acontecer.
>
>  O meu próximo passo, caso minha conclusão esteja correta, é fazer com
> que a conexão via callfile aconteça para que o codec esteja preenchido
> corretamente no momento da execução do Dial. É possível isto acontecer de
> maneira fake sem que um sipphone real atenda a ligação?
>
>
>      -- Attempting call on SIP/Lucas for s em interno:1 (Retry 1)
> [May 25 04:55:29] NOTICE[27963][C-000004fc]: channel.c:5637
> __ast_request_and_dial: Unable to request channel SIP/Lucas
>     -- Executing [failed em interno:1] NoOp("OutgoingSpoolFailed",
> "31nnnnnnnn") in new stack
>     -- Executing [failed em interno:2] Set("OutgoingSpoolFailed",
> "NUMBER=31nnnnnnnnn") in new stack
>     -- Executing [failed em interno:3] NoOp("OutgoingSpoolFailed", "numero
> 31nnnnnnnnn") in new stack
>     -- Executing [failed em interno:4] Set("OutgoingSpoolFailed",
> "SIP_CODEC=gsm") in new stack
>     -- Executing [failed em interno:5] Set("OutgoingSpoolFailed",
> "SIP_CODEC_OUTBOUND=gsm") in new stack
>     -- Executing [failed em interno:6] Goto("OutgoingSpoolFailed",
> "testeamd2,s,1") in new stack
>     -- Goto (testeamd2,s,1)
>     -- Executing [s em testeamd2:1] Set("OutgoingSpoolFailed", "marca=0") in
> new stack
>     -- Executing [s em testeamd2:2] Set("OutgoingSpoolFailed",
> "SIP_CODEC=gsm") in new stack
>     -- Executing [s em testeamd2:3] Set("OutgoingSpoolFailed",
> "SIP_CODEC_OUTBOUND=gsm") in new stack
>     -- Executing [s em testeamd2:4] *Dial*("OutgoingSpoolFailed",
> "SIP/qualita/31nnnnnnn,,tT") in new stack
> [May 25 04:55:29] NOTICE[27963][C-000004fc]: chan_sip.c:29464
> sip_request_call: Asked to get a channel of unsupported format (*nothing*)
> while capability is (gsm|ulaw|alaw|h263|testlaw)
> [May 25 04:55:29] WARNING[27963][C-000004fc]: app_dial.c:2437
> dial_exec_full: Unable to create channel of type 'SIP' (cause 58 - Bearer
> capability not available)
>
>
>
>  Senhores, mais uma vez, muito obrigado pela atenção.
>
>  Atenciosamente
>  Ronaldo Toledo
>
>
>
>
> Em 23 de maio de 2013 09:34, Fernando - NextBilling IP Solutions <
> fernando em nextbilling.com.br> escreveu:
>
>>  Mais um coisa. Você comentou sobre o q850 não estar funcionando.
>>
>>
>>
>> Para funcionar, você deve ativar no sip.conf
>>
>>
>>
>> use_q850_reason = yes
>>
>>
>>
>> E então no desligamento da chamada, processar o : *
>> ${HASH(SIP_CAUSE,<channel-name>)}*
>>
>>
>>
>> Atenciosamente,
>>
>>
>>
>> *Fernando da Silva Santos*
>>
>> *CEO* – Chief Executive Officer
>>
>> *NextBilling IP Solutions*
>>
>> * *
>>
>> *SP: *+55 (11) 3522-9200 <%2B55%20%2811%29%203522-9200>
>>
>> *RJ: *+55 (21) 4063-8854 <%2B55%20%2821%29%204063-8854>
>>
>> *Tollfree:* 0800 580-9200
>>
>> http://www.nextbilling.com.br
>>
>>
>>
>> *De:* asteriskbrasil-bounces em listas.asteriskbrasil.org [mailto:
>> asteriskbrasil-bounces em listas.asteriskbrasil.org] *Em nome de *Fernando
>> - NextBilling IP Solutions
>> *Enviada em:* quinta-feira, 23 de maio de 2013 09:22
>> *Para:* asteriskbrasil em listas.asteriskbrasil.org
>> *Assunto:* [AsteriskBrasil] RES: RES: RES: Asterisk não detecta
>> atendimento pela operadora
>> *Prioridade:* Alta
>>
>>
>>
>> Caro Ronaldo.
>>
>>
>>
>> Você chegou a tirar o siptrace da chamada em questão?
>>
>>
>>
>> Precisa tirar o siptrace para verificar a o que seu Tronco permite de
>> Gateway.
>>
>>
>>
>> Você pode forçar a utilização de um Codec no call file, usando o Set:
>>
>>
>>
>> Set: SIP_CODEC=g729
>>
>> Set: SIP_CODEC_OUTBOUND=g729
>>
>>
>>
>> Esse poderia ser um belo ponto de partida.
>>
>>
>>
>> O que o Mike disse, é o caminho que eu segui, ou seja, usando através do
>> Callfile chamar um Local Channel:
>>
>>
>>
>> Channel: Local/123 em contexto/n
>>
>> Set: SIP_CODEC=g729
>>
>> Set: SIP_CODEC_OUTBOUND=g729
>>
>>
>>
>> [contexto]
>>
>> exten => _X.,1,Dial(SIP/tronco/${EXTEN},,tT)
>>
>>
>>
>> Atenciosamente,
>>
>>
>>
>> *Fernando da Silva Santos*
>>
>> *CEO* – Chief Executive Officer
>>
>> *NextBilling IP Solutions*
>>
>> * *
>>
>> *SP: *+55 (11) 3522-9200 <%2B55%20%2811%29%203522-9200>
>>
>> *RJ: *+55 (21) 4063-8854 <%2B55%20%2821%29%204063-8854>
>>
>> *Tollfree:* 0800 580-9200
>>
>> http://www.nextbilling.com.br
>>
>>
>>
>> *De:* asteriskbrasil-bounces em listas.asteriskbrasil.org [
>> mailto:asteriskbrasil-bounces em listas.asteriskbrasil.org<asteriskbrasil-bounces em listas.asteriskbrasil.org>]
>> *Em nome de *Mike Tesliuk
>> *Enviada em:* quarta-feira, 22 de maio de 2013 23:24
>> *Para:* asteriskbrasil em listas.asteriskbrasil.org
>> *Assunto:* Re: [AsteriskBrasil] RES: RES: Asterisk não detecta
>> atendimento pela operadora
>>
>>
>>
>>
>> Entendi o seu caso,
>>
>> Bom, não sei como ele poderia pegar o hangup cause neste caso, porém oque
>> você falou de mandar a chamada para um contexto é oque eu faço até para ter
>> mais flexbilidade, você pode usar o Local/NUMERO em contexto  invez do
>> SIP/operadora/numero para fazer isso, de qualquer forma, acho estranho o
>> seu caso, nunca tive problema similar, mas nas ultimas operações de
>> discagem que fiz também não usei asterisk acabei usando o NewFies com
>> Freeswitch pq achei bem interessante e me atendia na situação.
>>
>> em todo caso, normalmente eu por questões de tarifação e tudo mais
>> costumo ter uma maquina para rodar a aplicação e outra para ser o gateway
>> desta, então eu (asterisk N2) sempre recebo a chamada e faço os devidos
>> tratamentos , acho que talvez por isso nunca tive este problema.
>>
>> Em 22/05/13 21:14, Ronaldo Toledo escreveu:
>>
>>  Mike, o meu problema é, na verdade, pegar o código que o meu tronco sip
>> me repassa ao ligar para os tais números.
>>
>> Quando uso o call file, ele me repassa aquele REASON 8, CONGESTION(se não
>> estou  enganado), o código guarda-chuva que se aplica a uma série de erros.
>> O HANGUPCAUSE  seria a variável que eu imaginei me servir, mas, até onde
>> li, ele só seria aplicável ao Dial,  o que me levou a alterar  a lógica
>> para que o Asterisk executasse um certo contexto e ali dentro eu faria o
>> Dial e teria o código de erro em HANGUPCAUSE. O inesperado é que a mesma
>> conexão, que acontece com o call file, não acontece com o Dial devido ao
>> erro que citei e que vc recomendou ligar o debug para tentar diagnosticar.
>> Eu fiz isto, mas o debug só mostrou os eventos relacionados a chamada do
>> call file e não reportou os eventos do Dial(talvez porque ele nem chegou a
>> iniciar a conversa com o tronco)
>>
>>
>> O Fernando, que também participa desta thread, disse que é possível, sim,
>> usar o HANGUPCAUSE para Call Files e me pediu que eu postasse o call file e
>> o contexto do dialplan, mas ele ainda não retornou.
>>
>>
>>
>>
>>
>> Em 22 de maio de 2013 12:32, Mike Tesliuk <mike em tesliuk.com> escreveu:
>>
>>  Tudo bem que voce nao alterou, porém veja o seguinte, ele reclamou que
>> nao conseguiu estabelecer um codec, então habilite o debug e veja oque voce
>> ta fazendo, talvez voce esteja pegando uma rota que o cara esteja te
>> jogando 729 e voce nao tenha, enfim, veja esta questão.
>>
>> Em 22/05/13 11:23, Ronaldo Toledo escreveu:
>>
>>   Eis o call file
>>
>> Channel: SIP/tronco/numtel
>> Context: testeamd
>> extension: s
>> priority: 1
>> waittime: 30
>> Set:LINHACSV=xxxxxxxxxxxxxxxxxxx*#*55*#*31*#*numtel
>>
>> O contexto testeamd no dialplan
>>
>> [testeamd]
>> exten => s,1,Set(marca=0)
>> exten => s,n,Noop(Telefone chamado ${EXTEN})
>> exten => s,n,Playback(/usr/local/projetoamd/teste)
>> exten => s,n,AMD
>> exten => s,n,GotoIf($[${AMDSTATUS}=HUMAN]?humano)
>> exten => s,n,GotoIf($[${AMDSTATUS}=MACHINE]?maquina)
>> exten => s,n,GotoIf($[${AMDSTATUS}=NOTSURE]?duvida)
>> exten => s,n,GotoIf($[${AMDSTATUS}=HANGUP]?desligou)
>> exten => s,n(maquina),WaitForSilence(2500)
>> exten => s,n,System(/usr/local/projetoamd/registrar.pl "${LINHACSV}"
>> "Maquina")
>> exten => s,n,Set(marca=1)
>> exten => s,n,Hangup
>> exten => s,n(humano),WaitForSilence(500)
>> exten => s,n,System(/usr/local/projetoamd/registrar.pl "${LINHACSV}"
>> "Humano")
>> exten => s,n,Set(marca=1)
>> exten => s,n,Hangup
>> exten => s,n(duvida),WaitForSilence(500)
>> exten => s,n,System(/usr/local/projetoamd/registrar.pl "${LINHACSV}"
>> "Duvida")
>> exten => s,n,Set(marca=1)
>> exten => s,n,Hangup
>>
>> exten => h,1,GotoIf($["${marca}" = "1"]?getout)
>> exten => h,n,System(/usr/local/projetoamd/registrar.pl "${LINHACSV}"
>> "Desligou")
>> exten => h,n(getout),Hangup()
>>
>> exten => failed,1,Set(marca=1)
>> exten => failed,n,Noop(${REASON})
>> exten => failed,n,Verbose(hangupcause = ${HANGUPCAUSE})
>> exten => failed,n,GotoIf($["${REASON}" != "8"]?ocupado)
>> exten => failed,n,System(/usr/local/projetoamd/registrar.pl"${LINHACSV}" "Maquina")
>> exten => failed,n,Hangup()
>> exten => failed,n(ocupado),GotoIf($["${REASON}" != "5"]?naoatendeu)
>> exten => failed,n,System(/usr/local/projetoamd/registrar.pl"${LINHACSV}" "Ocupado")
>> exten => failed,n,Hangup()
>> exten => failed,n(naoatendeu),System(/usr/local/projetoamd/registrar.pl"${LINHACSV}" "Cliente nao atendeu")
>> exten => failed,n,Hangup()
>>
>> Obrigado.
>>
>>
>>
>>
>>
>>
>>
>>
>> Em 22 de maio de 2013 12:09, Fernando - NextBilling IP Solutions <
>> fernando em nextbilling.com.br> escreveu:
>>
>>  Posta a parte principal que realiza a chamada pra gente ver como você
>> ta gerando ela.
>>
>>
>>
>> Posta também o seu callfile, pois deveria funcionar o hangupcause mesmo
>> através de callfile, já o fiz aqui, se você montar a lógica entre o
>> callfile e para onde ele envia a chamada depois de conectada tem que
>> funcionar.
>>
>> Atenciosamente,
>>
>>
>>
>> *Fernando da Silva Santos*
>>
>> *CEO* – Chief Executive Officer
>>
>> *NextBilling IP Solutions*
>>
>> * *
>>
>> *SP: *+55 (11) 3522-9200 <%2B55%20%2811%29%203522-9200>
>>
>> *RJ: *+55 (21) 4063-8854 <%2B55%20%2821%29%204063-8854>
>>
>> *Tollfree:* 0800 580-9200
>>
>> http://www.nextbilling.com.br
>>
>>
>>
>> *De:* asteriskbrasil-bounces em listas.asteriskbrasil.org [mailto:
>> asteriskbrasil-bounces em listas.asteriskbrasil.org] *Em nome de *Mike
>> Tesliuk
>> *Enviada em:* quarta-feira, 22 de maio de 2013 12:01
>> *Para:* asteriskbrasil em listas.asteriskbrasil.org
>> *Assunto:* Re: [AsteriskBrasil] RES: Asterisk não detecta atendimento
>> pela operadora
>>
>>
>>
>> parece erro de codec, veja os formatos que voce ta mandando e os que eles
>> aceitam, voce pode ver isso no debug
>>
>> Em 22/05/13 10:41, Ronaldo Toledo escreveu:
>>
>>  Amigos, com as respostas recebidas imaginei que fosse uma questão de ir
>> atrás de uma variável que, usada no dialplan, contivesse o código de erro
>> sip. Tentei o HANGUPCAUSE (a versão do meu asterisk é 11.3.0) mas ela
>> estava vazia durante a execução da extension failed,1 (estou usando call
>> files).
>>
>> Tentei usar o ${HASH(SIP_CAUSE,${CDR(dstchannel)})} e também não
>> funcionou. Depois de muito pesquisar descobri que elas se aplicam ao Hangup
>> que se segue a um  Dial. Tive que mudar minha estratégia.
>>
>> Minha aplicação previa o envio de uma série de call files ao Asterisk.
>> Prossegui com os call files para que fosse feita uma conexão fantasma  só
>> para que o Asterisk, ao executar a extensão failed do contexto
>> especificado, fosse desviado para um outro contexto onde seria feita a
>> ligação através de Dial  para o número passado via variável no call file.
>>
>> Bem, aí veio o problema maior. Ao executar o
>> Dial(SIP/troncomeuprovedor/numero), invariavelmente recebo as mensagens
>> [May 22 05:21:35] NOTICE[16975][C-00000436]: chan_sip.c:29464
>> sip_request_call: Asked to get a channel of unsupported format (nothing)
>> while capability is (gsm|ulaw|alaw|h263|testlaw)
>> [May 22 05:21:35] WARNING[16975][C-00000436]: app_dial.c:2437
>> dial_exec_full: Unable to create channel of type 'SIP' (cause 58 - Bearer
>> capability not available)
>>
>> Não consigo passar deste ponto
>>
>>
>>
>> Continuo pesquisando via Google o que está errado  mas se alguém já
>> passou por isso ou sabe a razão, por favor, jogue uma luz no assunto.
>>
>>
>>
>>
>>
>> Em 21 de maio de 2013 21:59, Ronaldo Toledo <rtmorais em gmail.com>
>> escreveu:
>>
>>  Fernando e Rafael, muito obrigado pelas respostas.
>>
>> Liguei o debug(deveria ter feito isto antes, né?) e voilá: o tronco
>> responde 503 (Service Unavailable).
>>
>> Mais uma vez, muito obrigado.
>>
>> Ronaldo Toledo.
>>
>>
>>
>>
>>
>> Em 21 de maio de 2013 21:51, Fernando - NextBilling IP Solutions <
>> fernando em nextbilling.com.br> escreveu:
>>
>>    Ronaldo.
>>
>>
>>
>> Nesses casos, geralmente o retorno é feito pelo seu tronco SIP, ou seja,
>> o Asterisk vai agir de acordo com o retorno que seu tronco SIP informar.
>>
>>
>>
>> Já vi casos em que troncos SIP retornam SIP Reason 503 para números
>> inválidos, e já vi casos em que o tronco SIP retorna SIP 404 para para
>> números inválidos.
>>
>>
>>
>> Eu sugiro a você analisar o siptrace do retorno do seu Tronco quando
>> ligar para esses números, pode ser um bom ponto de partida para analisar o
>> que ele realmente retorna.
>>
>>
>>
>> Crusando essa informação com o ISDN Code de cada retorno, seria mais
>> fácil para você ter um ponto de partida.
>>
>>
>>
>> Sip set debug peer NAME_DO_PEER ou sip set debug IP IP_DO_PEER
>>
>>
>>
>> Atenciosamente,
>>
>>
>>
>> *Fernando da Silva Santos*
>>
>> *CEO* – Chief Executive Officer
>>
>> *NextBilling IP Solutions*
>>
>> * *
>>
>> *SP: *+55 (11) 3522-9200 <%2B55%20%2811%29%203522-9200>
>>
>> *RJ: *+55 (21) 4063-8854 <%2B55%20%2821%29%204063-8854>
>>
>> *Tollfree:* 0800 580-9200
>>
>> http://www.nextbilling.com.br
>>
>>
>>
>> *De:* asteriskbrasil-bounces em listas.asteriskbrasil.org [mailto:
>> asteriskbrasil-bounces em listas.asteriskbrasil.org] *Em nome de *Ronaldo
>> Toledo
>> *Enviada em:* terça-feira, 21 de maio de 2013 20:20
>> *Para:* Alexandre Keller
>> *Assunto:* [AsteriskBrasil] Asterisk não detecta atendimento pela
>> operadora
>>
>>
>>
>> Olá.
>>
>> Estou com um problema que já pesquisei aqui e ali: Tento ligar via tronco
>> SIP para uma série de números de telefones e a coisa vai bem até que
>> encontro pela frente números de telefones como (51)32216470 E
>> (51)32254067.  O asterisk assume um comportamento errático para eles,
>> ora dá como ocupado(reason 8), ora dá que não atendeu(reason 3). Se faço a
>> ligação por meio de tel fixo ou celular, o atendimento é feito pela
>> operadora que sugere que o número não é válido.
>>
>> Por que o Asterisk não identifica o atendimento pela operadora? Alguém já
>> passou por este problema usando SIP?
>>
>> Existe ocorrências reportando problemas de atendimento com placas digium,
>> digivoice etc..... mas não com SIP.
>>
>> Ronaldo Toledo Morais.
>>
>>
>>
>>
>>
>> _______________________________________________
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>> Intercomunicadores para acesso remoto via rede IP. Conheça em
>> www.Khomp.com.
>> _______________________________________________
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>> _______________________________________________
>> Para remover seu email desta lista, basta enviar um email em branco para
>> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>>
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>>
>> Intercomunicadores para acesso remoto via rede IP. Conheça em www.Khomp.com.
>>
>> _______________________________________________
>>
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>>
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>>
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>>
>> _______________________________________________
>>
>> Para remover seu email desta lista, basta enviar um email em branco para asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>>
>>
>>
>> _______________________________________________
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>> Intercomunicadores para acesso remoto via rede IP. Conheça em
>> www.Khomp.com.
>> _______________________________________________
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>> _______________________________________________
>> Para remover seu email desta lista, basta enviar um email em branco para
>> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>>
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>>
>> Intercomunicadores para acesso remoto via rede IP. Conheça em www.Khomp.com.
>>
>> _______________________________________________
>>
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>>
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>>
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>>
>> _______________________________________________
>>
>> Para remover seu email desta lista, basta enviar um email em branco para asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>>
>>
>>
>> _______________________________________________
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>> Intercomunicadores para acesso remoto via rede IP. Conheça em
>> www.Khomp.com.
>> _______________________________________________
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>> _______________________________________________
>> Para remover seu email desta lista, basta enviar um email em branco para
>> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>>
>>
>>
>>
>>  _______________________________________________
>>
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>>
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>>
>> Intercomunicadores para acesso remoto via rede IP. Conheça em www.Khomp.com.
>>
>> _______________________________________________
>>
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>>
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>>
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>>
>> _______________________________________________
>>
>> Para remover seu email desta lista, basta enviar um email em branco para asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>>
>>
>> _______________________________________________
>> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
>> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
>> Intercomunicadores para acesso remoto via rede IP. Conheça em
>> www.Khomp.com.
>> _______________________________________________
>> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
>> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
>> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
>> _______________________________________________
>> Para remover seu email desta lista, basta enviar um email em branco para
>> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>>
>
>
>
> _______________________________________________
> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
> Intercomunicadores para acesso remoto via rede IP. Conheça em www.Khomp.com.
> _______________________________________________
> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
> _______________________________________________
> Para remover seu email desta lista, basta enviar um email em branco para asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>
>
>
> _______________________________________________
> KHOMP: completa linha de placas externas FXO, FXS, GSM e E1;
> Media Gateways de 1 a 64 E1s para SIP com R2, ISDN e SS7;
> Intercomunicadores para acesso remoto via rede IP. Conheça em
> www.Khomp.com.
> _______________________________________________
> ALIGERA – Fabricante nacional de Gateways SIP-E1 para R2, ISDN e SS7.
> Placas de 1E1, 2E1, 4E1 e 8E1 para PCI ou PCI Express.
> Channel Bank – Appliance Asterisk - Acesse www.aligera.com.br.
> _______________________________________________
> Para remover seu email desta lista, basta enviar um email em branco para
> asteriskbrasil-unsubscribe em listas.asteriskbrasil.org
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20130606/3d021f5a/attachment-0001.htm 


Mais detalhes sobre a lista de discussão AsteriskBrasil