[AsteriskBrasil] RES: RES: RES: Problemas Graves com Registro

Segunda Outubro 20 15:14:01 BRST 2008

E por que não isso:

register => 1122223333:senha1 em provedor_voip/1122223333
register => 1122224444:senha2 em provedor_voip/1122224444
register => 1122225555:senha3 em provedor_voip/1122225555

[saida_1]
type=peer
username=1122223333
fromuser=1122223333
secret=senha1
host=provedor_voip
context=entrada
insecure=invite,port

[saida_2]
type=peer
username=1122224444
fromuser=1122224444
secret=senha2
host=provedor_voip
context=entrada
insecure=invite,port

[saida_3]
type=peer
username=1122225555
fromuser=1122225555
secret=senha3
host=provedor_voip
context=entrada
insecure=invite,port

E no extensions.conf:

[entrada]
Exten => 1122223333,1,NoOp(do something fun here ...)
Exten => 1122224444,1,NoOp(do something fun here ...)
Exten => 1122225555,1,NoOp(do something fun here ...)

O Asterisk não deve requisitar um challenge para um PROXY e/ou Softswitch
quando vem uma chamada entrante (INVITE), por isso, usamos o insecure.
O match do peer é feito pelo host= por isso ele achou o saída_3 nesse caso,
como definimos o context= para todos os peers, não precisamos nos preocupar,
pois as chamadas entrantes serão tratadas no contexto comum - entrada. E
como usamos o username como endereço do contact, poderemos tratar
separadamente cada conta no contexto de entrada. Simples e eficaz.

--
Alexandre Abreu
RedT Telecom
http://www.redt.com.br

-----Mensagem original-----
De: asteriskbrasil-bounces em listas.asteriskbrasil.org
[mailto:asteriskbrasil-bounces em listas.asteriskbrasil.org] Em nome de Junior
Polegato - Asterisk
Enviada em: segunda-feira, 20 de outubro de 2008 14:33
Para: asteriskbrasil em listas.asteriskbrasil.org
Assunto: Re: [AsteriskBrasil] RES: RES: Problemas Graves com Registro

Alexandre Abreu escreveu:
> Já que essa é um lista técnica e sobre Asterisk, nada nos impede de
> continuar discutindo esse assunto, certo? ;-)
> Você poderia me explicar *tecnicamente* e colocar um exemplo real do
motivo
> que torna necessário o uso de 2 contextos (in/out)? E ainda nos explicar
que
> tipo de falhas você teve no recebimento e na realização de chamadas
(usando
> apenas um)?
>   

Ok. Se eu tiver várias contas no mesmo provedor VoIP, faço:

register => 1122223333:senha1 em provedor_voip
register => 1122224444:senha2 em provedor_voip
register => 1122225555:senha3 em provedor_voip

Aí segue:

[saida_1]
type=peer
username=1122223333
fromuser=1122223333
secret=senha1
host=provedor_voip

[saida_2]
type=peer
username=1122224444
fromuser=1122224444
secret=senha2
host=provedor_voip

[saida_3]
type=peer
username=1122225555
fromuser=11222255555
secret=senha3
host=provedor_voip

[entrada]
type=peer
host=provedor_voip
context=entrada

Agora, se tiro este último contexto e passo as outras para friend, ou 
deixo em peer mesmo, tenho:

CLI> sip debug
SIP Debugging enabled
CLI>
<-- SIP read from provedor_voip:5060:
INVITE sip:1122223333 em ip_asterisk:porta_asterisk;user=phone SIP/2.0
Via: SIP/2.0/UDP provedor_voip:5060;branch=z9hG4bK8746049ce5d4081b4d315e242
Call-ID: SBC63795294a57957a7233a5c94590b297d em 172.31.0.10
From: <sip:1_numero_origem em provedor_voip;user=phone>;tag=c1424d06
To: <sip:22223333 em ip_asterisk;user=phone>
CSeq: 1 INVITE
Allow: 
INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,ME
SSAGE,REFER
Max-Forwards: 70
Supported: 100rel
User-Agent: Huawei SoftX3000
Contact: <sip:1_numero_origem em provedor_voip:5060;user=phone>
Content-Length: 331
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 8729110 8729110 IN IP4 provedor_voip
s=Sip Call
c=IN IP4 provedor_voip
t=0 0
m=audio 12578 RTP/AVP 18 8 0 4 2 97
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=fmtp:18 annexb=yes
--- (13 headers 14 lines) ---
Using INVITE request as basis request - 
SBC63795294a57957a7233a5c94590b297d em 172.31.0.10
Sending to provedor_voip : 5060 (non-NAT)
Found peer 'saida_3'
Reliably Transmitting (no NAT) to provedor_voip:5060:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 
provedor_voip:5060;branch=z9hG4bK8746049ce5d4081b4d315e242;received=provedor
_voip
From: <sip:1_numero_origem em provedor_voip;user=phone>;tag=c1424d06
To: <sip:22223333 em ip_asterisk;user=phone>;tag=as0b1003a4
Call-ID: SBC63795294a57957a7233a5c94590b297d em 172.31.0.10
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1df46de6"
Content-Length: 0

---
<-- SIP read from provedor_voip:5060:
ACK sip:1122223333 em ip_asterisk:porta_asterisk;user=phone SIP/2.0
Via: SIP/2.0/UDP provedor_voip:5060;branch=z9hG4bK8746049ce5d4081b4d315e242
Call-ID: SBC63795294a57957a7233a5c94590b297d em 172.31.0.10
From: <sip:1_numero_origem em provedor_voip;user=phone>;tag=c1424d06
To: <sip:22223333 em ip_asterisk;user=phone>;tag=as0b1003a4
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

--- (8 headers 0 lines) ---

Assim, não tenho a chamada completada e dá erro. E tem casos, ainda não 
identifiquei por partir para a solução de entrada separada, que isso 
fica indefinidamente e a linha fica presa não podendo fazer e nem 
receber ligações...

Neste caso, por exemplo, tem alguma idéia melhor do que criar um 
contexto sip de entrada separado?

[]'s
           Junior Polegato

_______________________________________________
Compre uma camiseta da AsteriskBrasil.org!
http://www.voipmania.com.br

Acesse o canal IRC de discussão sobre Asterisk em Português Brasileiro na
rede Freenode.net: #asterisk-br
_______________________________________________
Lista de discussões AsteriskBrasil.org
AsteriskBrasil em listas.asteriskbrasil.org
http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil