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

Sábado Maio 25 05:19:07 BRT 2013

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****
>
> *RJ: *+55 (21) 4063-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****
>
> *RJ: *+55 (21) 4063-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****
>
> *RJ: *+55 (21) 4063-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****
>
> *RJ: *+55 (21) 4063-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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20130525/b0bae98f/attachment-0001.htm 