0

Kamailio v3.3.3 Released

Posted by admin on dez 18, 2012 in VOIP

Kamailio SIP Server v3.3.3 stable is out – a minor release including fixes in code and documentation since v3.3.2 – configuration file and database compatibility is preserved.

Kamailio (former OpenSER) v3.3.3 is based on the latest version of GIT branch 3.3, therefore those running previous 3.3.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v3.3.x.

Resources for Kamailio version 3.3.3

Source tarballs are available at:

Detailed changelog:

Download via GIT:

  # git clone –depth 1 git://git.sip-router.org/sip-router kamailio
 # cd kamailio
 # git checkout -b 3.3 origin/3.3
 # make FLAVOUR=kamailio cfg 

Binaries and packages will be uploaded at:

Modules’ documentation:

What is new in 3.3.x release series is summarized in the announcement of v3.3.0:

 
0

Asterisk variable Hangupcause

Posted by Gustavo on jul 3, 2012 in Telecom, Telefonia, VOIP

/* Causes for disconnection (from Q.931) */

  1. define AST_CAUSE_UNALLOCATED 1
  2. define AST_CAUSE_NO_ROUTE_TRANSIT_NET 2
  3. define AST_CAUSE_NO_ROUTE_DESTINATION 3
  4. define AST_CAUSE_CHANNEL_UNACCEPTABLE 6
  5. define AST_CAUSE_CALL_AWARDED_DELIVERED 7
  6. define AST_CAUSE_NORMAL_CLEARING 16
  7. define AST_CAUSE_USER_BUSY 17
  8. define AST_CAUSE_NO_USER_RESPONSE 18
  9. define AST_CAUSE_NO_ANSWER 19
  10. define AST_CAUSE_CALL_REJECTED 21
  11. define AST_CAUSE_NUMBER_CHANGED 22
  12. define AST_CAUSE_DESTINATION_OUT_OF_ORDER 27
  13. define AST_CAUSE_INVALID_NUMBER_FORMAT 28
  14. define AST_CAUSE_FACILITY_REJECTED 29
  15. define AST_CAUSE_RESPONSE_TO_STATUS_ENQUIRY 30
  16. define AST_CAUSE_NORMAL_UNSPECIFIED 31
  17. define AST_CAUSE_NORMAL_CIRCUIT_CONGESTION 34
  18. define AST_CAUSE_NETWORK_OUT_OF_ORDER 38
  19. define AST_CAUSE_NORMAL_TEMPORARY_FAILURE 41
  20. define AST_CAUSE_SWITCH_CONGESTION 42
  21. define AST_CAUSE_ACCESS_INFO_DISCARDED 43
  22. define AST_CAUSE_REQUESTED_CHAN_UNAVAIL 44
  23. define AST_CAUSE_PRE_EMPTED 45
  24. define AST_CAUSE_FACILITY_NOT_SUBSCRIBED 50
  25. define AST_CAUSE_OUTGOING_CALL_BARRED 52
  26. define AST_CAUSE_INCOMING_CALL_BARRED 54
  27. define AST_CAUSE_BEARERCAPABILITY_NOTAUTH 57
  28. define AST_CAUSE_BEARERCAPABILITY_NOTAVAIL 58
  29. define AST_CAUSE_BEARERCAPABILITY_NOTIMPL 65
  30. define AST_CAUSE_CHAN_NOT_IMPLEMENTED 66
  31. define AST_CAUSE_FACILITY_NOT_IMPLEMENTED 69
  32. define AST_CAUSE_INVALID_CALL_REFERENCE 81
  33. define AST_CAUSE_INCOMPATIBLE_DESTINATION 88
  34. define AST_CAUSE_INVALID_MSG_UNSPECIFIED 95
  35. define AST_CAUSE_MANDATORY_IE_MISSING 96
  36. define AST_CAUSE_MESSAGE_TYPE_NONEXIST 97
  37. define AST_CAUSE_WRONG_MESSAGE 98
  38. define AST_CAUSE_IE_NONEXIST 99
  39. define AST_CAUSE_INVALID_IE_CONTENTS 100
  40. define AST_CAUSE_WRONG_CALL_STATE 101
  41. define AST_CAUSE_RECOVERY_ON_TIMER_EXPIRE 102
  42. define AST_CAUSE_MANDATORY_IE_LENGTH_ERROR 103
  43. define AST_CAUSE_PROTOCOL_ERROR 111
  44. define AST_CAUSE_INTERWORKING 127

/* Special Asterisk aliases */

  1. define AST_CAUSE_BUSY AST_CAUSE_USER_BUSY
  2. define AST_CAUSE_FAILURE AST_CAUSE_NETWORK_OUT_OF_ORDER
  3. define AST_CAUSE_NORMAL AST_CAUSE_NORMAL_CLEARING
  4. define AST_CAUSE_NOANSWER AST_CAUSE_NO_ANSWER
  5. define AST_CAUSE_CONGESTION AST_CAUSE_NORMAL_CIRCUIT_CONGESTION
  6. define AST_CAUSE_NOTDEFINED 0

 

Recommended SIP <-> ISDN Cause codes (from RFC3398)

Note: Asterisk 1.8 will allow to read SIP response codes in the dialplan via

${HASH(SIP_CAUSE,<channel-name>)}

So slave SIP channels now set HASH(SIP_CAUSE,<slave-channel-name>) on each response. This permits the master channel to know how each channel dialed in a multi-channel setup resolved in an individual way.

Asterisk 1.8 also comes with a ‘use_q850_reason’ configuration option for generating and parsing, if available:

Reason: Q.850;cause=<cause code>

It is implemented in some gateways for better passing PRI/SS7 cause codes via SIP.
Tilghman: “The only reason we implemented the passing back of the raw SIP code in the dialplan is that the conversion to cause is lossy. That is, several SIP status codes all map back to a single ISUP cause code, and there are legitimate reasons for wanting to know which status code was received. What SHOULD happen is that if use_q850_reason is set, then the cause sent to the core should simply be the cause code in this new SIP header (“Reason: …”), which you should be able to read in ${HANGUPCAUSE}.”
The destination channel dies right after your Dial statement exits, but you can retrieve the info in the channel that’s still alive :
exten => _XXX,n,Dial(SIP/${EXTEN})
exten => _XXX,n,NoOp(SIP return code : ${HASH(SIP_CAUSE,${CDR(dstchannel)})})

 

ISUP Cause value SIP response

1 unallocated number 404 Not Found
2 no route to network 404 Not found
3 no route to destination 404 Not found
16 normal call clearing — (*)
17 user busy 486 Busy here
18 no user responding 408 Request Timeout
19 no answer from the user 480 Temporarily unavailable
20 subscriber absent 480 Temporarily unavailable
21 call rejected 403 Forbidden (+)
22 number changed (w/o diagnostic) 410 Gone
22 number changed (w/ diagnostic) 301 Moved Permanently
23 redirection to new destination 410 Gone
26 non-selected user clearing 404 Not Found (=)
27 destination out of order 502 Bad Gateway
28 address incomplete 484 Address incomplete
29 facility rejected 501 Not implemented
31 normal unspecified 480 Temporarily unavailable

 
Response received Cause value in the REL


400 Bad Request 41 Temporary Failure
401 Unauthorized 21 Call rejected (*)
402 Payment required 21 Call rejected
403 Forbidden 21 Call rejected
404 Not found 1 Unallocated number
405 Method not allowed 63 Service or option unavailable
406 Not acceptable 79 Service/option not implemented (+)
407 Proxy authentication required 21 Call rejected (*)
408 Request timeout 102 Recovery on timer expiry
410 Gone 22 Number changed (w/o diagnostic)
413 Request Entity too long 127 Interworking (+)
414 Request-URI too long 127 Interworking (+)
415 Unsupported media type 79 Service/option not implemented (+)
416 Unsupported URI Scheme 127 Interworking (+)
420 Bad extension 127 Interworking (+)
421 Extension Required 127 Interworking (+)
423 Interval Too Brief 127 Interworking (+)
480 Temporarily unavailable 18 No user responding
481 Call/Transaction Does not Exist 41 Temporary Failure
482 Loop Detected 25 Exchange – routing error
483 Too many hops 25 Exchange – routing error
484 Address incomplete 28 Invalid Number Format (+)
485 Ambiguous 1 Unallocated number
486 Busy here 17 User busy
487 Request Terminated — (no mapping)
488 Not Acceptable here — by Warning header
500 Server internal error 41 Temporary failure
501 Not implemented 79 Not implemented, unspecified
502 Bad gateway 38 Network out of order
503 Service unavailable 41 Temporary failure
504 Server time-out 102 Recovery on timer expiry
504 Version Not Supported 127 Interworking (+)
513 Message Too Large 127 Interworking (+)
600 Busy everywhere 17 User busy
603 Decline 21 Call rejected
604 Does not exist anywhere 1 Unallocated number
606 Not acceptable — by Warning header

(*) In some cases, it may be possible for a SIP gateway to provide
credentials to the SIP UAS that is rejecting an INVITE due to
authorization failure. If the gateway can authenticate itself, then
obviously it SHOULD do so and proceed with the call; only if the
gateway cannot authenticate itself should cause code 21 be sent.

(+) If at all possible, a SIP gateway SHOULD respond to these
protocol errors by remedying unacceptable behavior and attempting to
re-originate the session. Only if this proves impossible should the
SIP gateway fail the ISUP half of the call.

When the Warning header is present in a SIP 606 or 488 message, there
may be specific ISDN cause code mappings appropriate to the Warning
code. This document recommends that ’31 Normal, unspecified’ SHOULD
by default be used for most currently assigned Warning codes. If the
Warning code speaks to an unavailable bearer capability, cause code
’65 Bearer Capability Not Implemented’ is a RECOMMENDED mapping.

 
0

Qualidade de Voz no Voip

Posted by admin on ago 19, 2011 in VOIP

Jitter: É a variação do atraso entre pacotes. A transmissão de voz, ao contrário da transmissão de dados é susceptível de ser afectada pelo jitter. Uma demora excessiva entre o envio e recebimento de pacotes podem causar uma ligação de voz difícil de ouvir.

Mais Jitter1:

2.Jitter (Variação do atraso): Jitter é a varição do tempo de atraso da chegada do pacotes introduzida pela variação do atraso de transmissão da rede. Remover o jitter requer a retenção de pacotes por um tempo que seja suficiente para que o pacote mais lento chegue a tempo de ser executado na sequência correta, o que causa um delay adicional. O buffer necessário para corrigir o jitter adiciona atraso, que é usado para corrigir a variação do atraso a que cada pacote é submetido enquanto trafega pela rede.

Mais Jitter2:

Jitter é qualquer variação no eixo temporal de um sinal digital e está presente em todo lugar no universo digital. Em qualquer caso, a reprodução correta dos dados transmitidos pelo receptor é limitada pela precisão do clock recuperado.

Erros causados por jitter ocorrerão sempre na cadeia que o sinal percorre. O grande desafio é manter a influência do jitter abaixo do limiar de correção de erros do código em questão.

Jitter ocorre nos meios físicos (CD, DVD, etc), nos canais de tranmissão (cabos e trilhas), circuitos de processamento e nos conversores, entre outros.

É importante distinguir entre 2 tipos principais de jitter, os chamados interface jitter e sampling jitter . O primeiro ocorre em transferências digitais e só é significativo se causar erros incorrigíveis no sinal recebido. Se o sinal for recuperado sem erros, a influência total do jitter é nula, independente de seu valor absoluto. A tolerância aqui é da ordem de 5 a 10 ns.

O segundo, que ocorre nas conversões A/D e D/A, é muito mais crítico, somando ruído e distorções ao sinal recuperado. As tolerâncias nos clocks e circuitos regeneradores de clock deve ser muito rígida para minimizar seu efeito. A tolerância aqui é da ordem de 20 ps!!

Dependendo do projeto do circuito (e do custo desejado para o aparelho…) pode-se usar clocks duais nos receptores, onde um primeiro PLL extrai o clock do sinal e um segundo PLL regenera o clock a partir do primeiro, atenuando muito o efeito do jitter.

Pouco lembramos também que jitter é introduzido nos CDs e DVDs pela variação na velocidade de rotação do disco, que mesmo controlado por servomecanismos não é perfeita, tanto na gravação quanto na reprodução…

 

Fonte interessante para aprofundar o conhecimento sobre Jitter: http://www.jitter.de/english/engc_navfr.html

 

Perda de pacotes: A comunicação de voz sobre um pacote baseado em rede é menos tolerante a perda de pacotes do que o mesmo tipo de comunicação sobre uma rede comutada. Muitos pacotes perdidos podem degradar a qualidade de voz significativamente.

Sequência de pacotes: Devido à natureza das comunicações de voz, os pacotes recebidos precisam ser processados na mesma ordem em que foram enviados a partir da fonte original.

Eco acústivo: O eco acústico é o reflexo de um sinal sonoro. O poder ou a amplitude do eco acústico e a quantidade de atraso entre o sinal que causou e o sinal de reflexão (eco acústico) determina se o eco é detectado pelo alto-falante.

Frente a  estes problemas existem mecanismos diferentes.

Jitter Control: RTP e RTCP fornece informações como data e hora e os valores de jitter que as aplicações de comunicações em tempo real podem usar para compensar o jitter durante uma sessão. Os jitter buffers das aplicações utilizam os valores data, hora e jitter para fazer os ajustes necessários com a finalidade de que se receba um fluxo de pacotes continuo.
As aplicações utilizam as informações recebidas dos pacotes RTP e RTCP para calcular a diferença de dois pacotes.

Cancelador de eco acústico : Ao usar um PC para comunicação em tempo real, tais como chamadas de voz, os participantes da chamada podem experimentar o  eco acústico. Utilize um headset auricular ou um terminal VoIP que tem um microfone integrado ao alto-falante em vez de usar um microfone separado dos alto-falantes, isso pode excluir qualquer eco acústico. Para melhor controle do eco acústico, você precisa de um cancelador de AEC (cancelador de eco acústico, em Inglês).

Qualidade de Serviço (QoS) : Os protocolos RTP e RTCP o mecanismo de controle de jitter e o cancelador de eco acústico fornecem informações e ferramentas para monitorar os aplicativos e melhorar a qualidade das comunicações em tempo real.

Medindo a qualidade da voz : A escala Mean Opinion Score (MOS) fornece uma ferramenta para medir e avaliar a qualidade subjetiva da voz. A escala MOS tem um range de 1 a 5, onde 1 indica má qualidade e 5 indica excelente qualidade. A qualidade de voz no RTC (ou PSTN em Inglês) também conhecido como uma conferência é geralmente na faixa de 4 e 5 na escala MOS. Já que alguns codecs capturam um range mais amplo de freqüência eles poderão oferecer uma experiência melhor para o usuario com um som mais natural. A transmissão de voz sobre uma rede IP baseada em pacotes pode agora proporcionar uma qualidade melhor que a transmissão de voz sobre uma rede PSTN.

Nas transmissões de voz sobre redes de comutação de pacotes pode-se se ter uma qualidade melhor na chamada quando a latência é inferior a 200 milisegundos(ms). Mesmo com um retardo entre 200 e 400ms uma transmissão de voz é aceitável, mas quando o esse retardo ultrapassa a casa dos 400ms a qualidade do audio deixa de ser aceitável.

 
0

Provisioning para ATAs LinkSys PAP2

Posted by admin on ago 11, 2011 in Telecom, VOIP

Usando um tftp free, e também tem como utilizar um server web porém irei falar utilizando um tftp local

Instale um tftp server, por exemplo: SolarWinds TFTP, para testar por enquanto desabilite seu firewall ou abra a porta UDP 69.

a seguir crie um arquivo ata_conf.txt, salve este arquivo dentro do seu tftp server.

Configurando o arquivo de texto para que seu ATA pegue as configurações.

   <flat-profile>
	<Resync_Periodic>600</Resync_Periodic>
	
<!-- tag case appears to be important -->
<!-- configurações de usuário e senha do ata -->
 	<Admin_Passwd></Admin_Passwd>
 	<User_Passwd></User_Passwd>

<!-- system, optional network configuration -->
 	<HostName>spa</HostName>
 	<Domain>dominio.com.br</Domain>
 	<Primary_DNS>servidordns1</Primary_DNS>
 	<Secondary_DNS>servidordns2</Secondary_DNS>
 	<DNS_Server_Order>DHCP,Manual</DNS_Server_Order>
 	<Primary_NTP_Server>ntp.exemplo.com.br</Primary_NTP_Server>

<!-- line 1, proxy and registration -->
 	<Proxy_1_>voip.exemplo.com.br</Proxy_1_>

<!-- line 1, subscriber information -->
 	<Display_Name_1_>1001</Display_Name_1_>
 	<User_ID_1_>1001</User_ID_1_>
 	<Password_1_>supersenha</Password_1_>
	<Dial_Plan_1_>(000xxxxx.|0xxxxxxxx|0xxxxxxxxxxS0|00800xxxx.|1xxxS0|*8S0|*xx|xxx)</Dial_Plan_1_>

<!-- line 2, proxy and registration -->
 	<Proxy_2_>voip.exemplo.com.br</Proxy_2_>

<!-- line 2, subscriber information -->
 	<Display_Name_2_>1002</Display_Name_2_>
 	<User_ID_2_>1002</User_ID_2_>
 	<Password_2_>supersenha</Password_2_>
	<Dial_Plan_2_>(000xxxxx.|0xxxxxxxx|0xxxxxxxxxxS0|00800xxxx.|1xxxS0|*8S0|*xx|xxx)</Dial_Plan_2_>

	<Call_Return_Code></Call_Return_Code>
	<Blind_Transfer_Code></Blind_Transfer_Code>
	<Call_Back_Act_Code></Call_Back_Act_Code>
	<Call_Back_Deact_Code></Call_Back_Deact_Code>
	<Cfwd_All_Act_Code></Cfwd_All_Act_Code>
	<Cfwd_All_Deact_Code></Cfwd_All_Deact_Code>
	<Cfwd_Busy_Act_Code></Cfwd_Busy_Act_Code>
	<Cfwd_Busy_Deact_Code></Cfwd_Busy_Deact_Code>
	<Cfwd_No_Ans_Act_Code></Cfwd_No_Ans_Act_Code>
	<Cfwd_No_Ans_Deact_Code></Cfwd_No_Ans_Deact_Code>
	<Cfwd_Last_Act_Code></Cfwd_Last_Act_Code>
	<Cfwd_Last_Deact_Code></Cfwd_Last_Deact_Code>
	<Block_Last_Act_Code></Block_Last_Act_Code>
	<Block_Last_Deact_Code></Block_Last_Deact_Code>
	<Accept_Last_Act_Code></Accept_Last_Act_Code>
	<Accept_Last_Deact_Code></Accept_Last_Deact_Code>
	<CW_Act_Code></CW_Act_Code>
	<CW_Deact_Code></CW_Deact_Code>
	<CW_Per_Call_Act_Code></CW_Per_Call_Act_Code>
	<CW_Per_Call_Deact_Code></CW_Per_Call_Deact_Code>
	<Block_CID_Act_Code></Block_CID_Act_Code>
	<Block_CID_Deact_Code></Block_CID_Deact_Code>
	<Block_CID_Per_Call_Act_Code></Block_CID_Per_Call_Act_Code>
	<Block_CID_Per_Call_Deact_Code></Block_CID_Per_Call_Deact_Code>
	<Block_ANC_Act_Code></Block_ANC_Act_Code>
	<Block_ANC_Deact_Code></Block_ANC_Deact_Code>
	<DND_Act_Code></DND_Act_Code>
	<DND_Deact_Code></DND_Deact_Code>
	<CID_Act_Code></CID_Act_Code>
	<CID_Deact_Code></CID_Deact_Code>
	<CWCID_Act_Code></CWCID_Act_Code>
	<CWCID_Deact_Code></CWCID_Deact_Code>
	<Dist_Ring_Act_Code></Dist_Ring_Act_Code>
	<Dist_Ring_Deact_Code></Dist_Ring_Deact_Code>
	<Vertical_Service_Announcement_Codes></Vertical_Service_Announcement_Codes>
	<Time_Zone>GMT-03:00</Time_Zone>

</flat-profile>   

Copyright © 2013 Gustavo Franco All rights reserved. Theme by Laptop Geek.