[AsteriskBrasil] RES: Mensagem Maximum retries exceeded on transmission após hangup na chamada

[Alcapone Felippe]

É parece ser um problema entre a conexão do SipS  ao asterisk.

O asterisk depois de alguns segundos falando diz que não esta ok a conexão e o SipS derruba a chamada.

Já descartei ser codecs, pois já tentei de tudo.

 

Não sei mais o que fazer.

Fiz testes com outro asterisk na mesma versão e mesmo problema. Porem no terceiro asterisk que testei de mesma versão tudo funciona. Comparei os logs e vi que configurações e são as mesmas.

 

De asterisk para asterisk trunk sip funciona perfeito.

 

 

De: asteriskbrasil-bounces em listas.asteriskbrasil.org [mailto:asteriskbrasil-bounces em listas.asteriskbrasil.org] Em nome de Felippe
Enviada em: quarta-feira, 27 de outubro de 2010 16:34
Para: asteriskbrasil em listas.asteriskbrasil.org
Assunto: [AsteriskBrasil] Mensagem Maximum retries exceeded on transmission após hangup na chamada

 

Saudações.
  
    Veja se alguem consegue me ajudar na solucao deste problema:

    Estou tendo um problema quanto ao recebimento de chamadas no meu asterisk no qual não consigo identificar de onde pode esta vindo tal erro. Já perdi 3 dias tentando de tudo mas ainda nada deu certo. As chamadas são encaminhadas de um OpenSips ate ele. Ate 5 dias atras vinha funcionando a mais de 2 anos. Porem esse final de semana tive que trocar o servidor asterisk no qual recebe as chamdas e reinstalei tudo novamente. Mesma versao do asterisk, etc. Porem começou esses problema.
Tenho uma URA de entrada, entao o cliente escuta a opcao de 1 a 10 por exemplo. Ele liga no meu DID ou liga do Opensips que encaminha para meu asterisk, ouve a URA e na quarta ou quinta opcao fica mudo e tenho a mensagem na cli:
Não estou atras de NAT, o asterisk faz a conexao pppoe. 
Versao 1.4.21.2

[Oct 27 16:03:01] WARNING[12859]: chan_sip.c:1950 retrans _pkt: Maximum retries exceeded on transmission 41D42534-E12B11DF-B9A2BFFB-47F79513 em 200.200.200.200 for seqno 101 (Critical Response)
[Oct 27 16:03:01] WARNING[12859]: chan_sip.c:1972 retrans_pkt: Hanging up call 41D42534-E12B11DF-B9A2BFFB-47F79513 em 200.200.200.200 - no reply to our critical packet.
  == Spawn extension (ura_comeco, s, 1) exited non-zero on 'SIP/provedor-08d3c9b8'


Nao sei se posso enviar o debug por aqui mas ja enviando.. tenho isso em todo inicio ao final:


t 27 16:26:11] DEBUG[13421]: pbx.c:1842 pbx_extension_helper: Launching 'Wait'
    -- Executing [s em ura:5] Wait("SIP/provedor-08a7cbc8", "1") in new stack
[Oct 27 16:26:11] DEBUG[13365]: devicestate.c:287 do_state_change: Changing state for SIP/provedor-08a7cbc8 - state 4 (Invalid)
[Oct 27 16:26:11] D EBUG[13365]: devicestate.c:161 ast_device_state: No provider found, checking channel drivers for SIP - provedor
[Oct 27 16:26:11] DEBUG[13365]: chan_sip.c:16004 sip_devicestate: Checking device state for peer provedor
[Oct 27 16:26:11] DEBUG[13382]: app_queue.c:659 handle_statechange: Device 'SIP/provedor-08a7cbc8' changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
[Oct 27 16:26:11] DEBUG[13365]: devicestate.c:287 do_state_change: Changing state for SIP/provedor- state 4 (Invalid)
[Oct 27 16:26:11] DEBUG[13365]: devicestate.c:161 ast_device_state: No provider found, checking channel drivers for SIP - provedor-08a7cbc8
[Oct 27 16:26:11] DEBUG[13365]: chan_sip.c:16004 sip_devicestate: Checking device state for peer provedor-08a7cbc8
[Oct 27 16:26:11] DEBUG[13382]: app_queue.c:659 handle_statechange: Device 'SIP/provedor changed to state '4' (Invalid) but we don't care because they're not a member of any que ue.
[Oct 27 16:26:11] DEBUG[13365]: devicestate.c:287 do_state_change: Changing state for SIP/provedor-08a7cbc8 - state 4 (Invalid)
[Oct 27 16:26:11] DEBUG[13365]: devicestate.c:161 ast_device_state: No provider found, checking channel drivers for SIP - provedor
[Oct 27 16:26:11] DEBUG[13365]: chan_sip.c:16004 sip_devicestate: Checking device state for peer provedor
[Oct 27 16:26:11] DEBUG[13382]: app_queue.c:659 handle_statechange: Device 'SIP/provedor-08a7cbc8' changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
[Oct 27 16:26:11] DEBUG[13365]: devicestate.c:287 do_state_change: Changing state for SIP/provedor- state 4 (Invalid)
[Oct 27 16:26:11] DEBUG[13382]: app_queue.c:659 handle_statechange: Device 'SIP/provedor changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
[Oct 27 16:26:12] DEBUG[13367]: chan_sip.c:1928 retrans_pkt: ** SIP timers: Rescheduling retran smission 2 to 200 ms (t1 100 ms (Retrans id #143))
[Oct 27 16:26:12] DEBUG[13367]: sched.c:204 sched_settime: Request to schedule in the past?!?!
[Oct 27 16:26:12] DEBUG[13367]: chan_sip.c:1928 retrans_pkt: ** SIP timers: Rescheduling retransmission 3 to 400 ms (t1 100 ms (Retrans id #143))
[Oct 27 16:26:12] DEBUG[13421]: pbx.c:1842 pbx_extension_helper: Launching 'GotoIfTime'
    -- Executing [s em ura:6] GotoIfTime("SIP/provedor-08a7cbc8", "7:55-19:30|mon-fri|*|*?ura_comeco|s|1(inicio)") in new stack
    -- Goto (ura_comeco,s,1)
[Oct 27 16:26:12] DEBUG[13421]: pbx.c:1842 pbx_extension_helper: Launching 'BackGround'
    -- Executing [s em ura_comeco:1] BackGround("SIP/provedor-08a7cbc8", "ura_inicio") in new stack
[Oct 27 16:26:12] DEBUG[13421]: channel.c:2808 set_format: Set channel SIP/provedor-08a7cbc8 to write format slin
[Oct 27 16:26:12] DEBUG[13421]: rtp.c:2769 ast_rtp_write: Ooh, format changed from unknown to g729
[Oct 27 16:26:12] DEBUG[13421]: rtp.c:2786 ast_rtp_write: Created smoother: format: 256 ms: 20 len: 20
[Oct 27 16:26:12] DEBUG[13421]: channel.c:1804 ast_settimeout: Scheduling timer at 160 sample intervals
    -- <SIP/provedor-08a7cbc8> Playing 'ura_inicio' (language 'pt_BR')
[Oct 27 16:26:13] DEBUG[13367]: chan_sip.c:1928 retrans_pkt: ** SIP timers: Rescheduling retransmission 4 to 800 ms (t1 100 ms (Retrans id #143))
[Oct 27 16:26:13] DEBUG[13367]: chan_sip.c:1928 retrans_pkt: ** SIP timers: Rescheduling retransmission 5 to 1600 ms (t1 100 ms (Retrans id #143))
[Oct 27 16:26:15] DEBUG[13421]: rtp.c:879 ast_rtcp_read: Got RTCP report of 136 bytes
[Oct 27 16:26:15] DEBUG[13367]: chan_sip.c:1928 retrans_pkt: ** SIP timers: Rescheduling retransmission 6 to 3200 ms (t1 100 ms (Retrans id #143))
[Oct 27 16:26:16] DEBUG[13421]: rtp.c:879 ast_rtcp_read: Got RTCP report of 136 bytes
[Oct 27 16:26:18] DEBUG[13367]: chan_sip.c:1928 retrans_pkt: ** SIP timers: Rescheduling retransmission 7 to 4000 ms (t1 100 ms (Retrans id #143))
[Oct 27 16:26:22] WARNING[13367]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission 85973717-E12E11DF-BF07BFFB-47F79513 em 200.200.200.200 <mailto:85973717-E12E11DF-BF07BFFB-47F79513 em 200.196.28.101>   for seqno 101 (Critical Response)
[Oct 27 16:26:22] DEBUG[13367]: chan_sip.c:1657 sip_alreadygone: Setting SIP_ALREADYGONE on dialog 85973717-E12E11DF-BF07BFFB-47F79513 em 200.200.200.200 [Oct 27 16:26:22] WARNING[13367]: chan_sip.c:1972 retrans_pkt: Hanging up call 85973717-E12E11DF-BF07BFFB-47F79513 em 200.200.200.200 <mailto:85973717-E12E11DF-BF07BFFB-47F79513 em 200.196.28.101>   - no reply to our critical packet.
[Oct 27 16:26:22] DEBUG[13421]: channel.c:1804 ast_settimeout: Scheduling timer at 0 sample intervals
[Oct 27 16:26:22] DEBUG[13421]: channel.c:2808 set_format: Set channel SIP/provedor-08a7cbc8 to write format g729
[Oct 27 16:26:22] DEBUG[13421]: pbx.c:2438 __ast_pbx_run: Spawn extension (ura_comeco,s,1) exited non-zero on 'SIP/provedor-08a7cbc8'
  == Spawn extension (ura_comeco, s, 1) exited non-zero on 'SIP/provedor-08a7cbc8'
[Oct 27 16:26:22] DEBUG[13421]: channel.c:1384 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/provedor-08a7cbc8'
[Oct 27 16:26:22] DEBUG[13421]: channel.c:1483 ast_hangup: Hanging up channel 'SIP/provedor-08a7cbc8'
[Oct 27 16:26:22] DEBUG[13421]: chan_sip.c:3522 sip_hangup: Hangup call SIP/provedor-08a7cbc8, SIP callid 85973717-E12E11DF-BF07BFFB-47F79513 em 200.200.200.200 )
[Oct 27 16:26:22] DEBUG[13421]: chan_sip.c:3210 update_call_counter: Updating call counter for incoming call


Cordial,
 
  Felippe 

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/attachments/20101028/74fd6768/attachment-0001.htm