Gracias Iñaki y Raul por sus respuestas, efectivamente la version con la que cuenta esta Central de Alcatel es una antigua y practicamente puedo decir que es obsoleta. Pero ahora me espera un gran reto proponer una plataforma en software libre con muchas funcionalidades, y demostrar que realmente funciona y que es mejor de la que tienen . En tal sentido he estado buscando info en la red y leyendo ps por alli me encontre OpenSer + Asterisk que me permite implementar una plataforma con muchas funcionalidades, No he encontrado mucha informacion practica de como integrarlo si por alli teneis alguna referencia seria de gran ayuda.
Muchas Gracias
Saludos
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
Hola, para salientes con número oculto a través de un determinado gateway
PST_SIP he testeado que se debe cumplir:
- Cabecera "PAI" válida (o sea, un username numérico).
- Cabecera "Privacy: id".
Entonces el receptor ve "Retenido".
Pero si pongo en el PAI algo no numérico (no PSTN):
P-Asserted-Identity: <sip:anonymous@IP>
y añado la cabecera "Privacy: id" entonces el receptor ve "Número desconocido"
ó "0" (un triste cero).
Supongo que si el gateway te acepta el PAI y le metes en él un número que "no
le sirve" entonces para él es desconocido e ignora el "Privacy: id" (que
funciona conjuntamente con el PAI). ¿Estoy en lo cierto?
¿Alguna mala experiencia con el tema de salientes de número oculto con otros
gateways? Gracias.
PD: También valdría RPID pero voy a usar sólo PAI.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola a todos..
Un pregunta un poco cochambrosa... tengo un ATA que cuando la llamada pasa
por asterisk, se que congelado, y si va por openser funciona perfecto... se
muere por lo "200 OK" que manda asterisk... el que recibe de Openser, es
COMPLETAMENTE distinto...
captura de tshark...
el de Openser:
Internet Protocol, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.1.116 (
192.168.1.116)
User Datagram Protocol, Src Port: 8342 (8342), Dst Port: 5060 (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: <sip:8889991@my.domain.com;user=phone>;tag=5636e002
From: 8888888<sip:8888888@my.domain.com;user=phone>;tag=6Scf2-18Yzu0
Via: SIP/2.0/UDP 192.168.1.116;branch=z9hG4bK486c.f39169b5.0
;received=192.168.1.116
Via: SIP/2.0/UDP 192.168.0.55:5060;rport=33654;received=
192.168.1.240;branch=z9hG4bKwE0f2-W2w7sRiu
Call-ID: 9RqF70-3dT0sf2(a)my.domain.com
CSeq: 103 INVITE
Record-Route: <sip:192.168.1.116;lr=on;ftag=6Scf2-18Yzu0>
Contact: <sip:8889991@192.168.1.180:8342;transport=udp>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 285
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 15858836 15859206 IN IP4
192.168.1.180
Session Name (s): eyeBeam
Connection Information (c): IN IP4 192.168.1.180
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8360 RTP/AVP 18
101
Media Type: audio
Media Port: 8360
Media Proto: RTP/AVP
Media Format: ITU-T G.729
Media Format: 101
Media Attribute (a): alt:1 1 : 3E824724 5CE3B7E1 192.168.1.1808360
Media Attribute Fieldname: alt
Media Attribute Value: 1 1 : 3E824724 5CE3B7E1 192.168.1.1808360
Media Attribute (a): alt:2 3 : 65F4C37E 6639080D 192.168.1.68360
Media Attribute Fieldname: alt
Media Attribute Value: 2 3 : 65F4C37E 6639080D 192.168.1.68360
Media Attribute (a): fmtp:101 0-15
Media Attribute Fieldname: fmtp
Media Format: 101
Media format specific parameters: 0-15
Media Attribute (a): sendrecv
el de asterisk:
Internet Protocol, Src: 192.168.1.116 (192.168.1.116), Dst: 192.168.0.67 (
192.168.0.67)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.168.0.67:5060;rport=33550;received=
192.168.1.109;branch=z9hG4bK6F0f2-gSHit0Vlv
Record-Route: <sip:192.168.1.116;lr=on;ftag=gVuf2-SJ*GZ0>
From: 8888888<sip:8888888@my.domain.com;user=phone>;tag=gVuf2-SJ*GZ0
To: <sip:8889991@my.domain.com;user=phone>;tag=as7e0858ab
Call-ID: 5dyHK-dgl020f2(a)my.domain.com
CSeq: 102 INVITE
User-Agent: CityMoon SIP/1.8.0.004
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:8889991@192.168.1.111:5099>
Content-Type: application/sdp
Content-Length: 263
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): root 7913 7914 IN IP4
192.168.1.111
Session Name (s): session
Connection Information (c): IN IP4 192.168.1.111
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 13124 RTP/AVP 18
101
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute Fieldname: rtpmap
Media Format: 18
MIME Type: G729
Media Attribute (a): fmtp:18 annexb=no
Media Attribute Fieldname: fmtp
Media Format: 18 [G729]
Media format specific parameters: annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 101
MIME Type: telephone-event
Media Attribute (a): fmtp:101 0-16
Media Attribute Fieldname: fmtp
Media Format: 101 [telephone-event]
Media format specific parameters: 0-16
Media Attribute (a): silenceSupp:off - - - -
Media Attribute Fieldname: silenceSupp
Media Attribute Value: off - - - -
Media Attribute (a): ptime:20
Media Attribute Fieldname: ptime
Media Attribute Value: 20
Media Attribute (a): sendrecv
Alguna idea de porqué es TAN distinto???
Saludos
Hoola!
Supongamos el siguiente escenario:
* Usuarios registrados en OpenSER.
* Asterisk con la info de los usuarios en RealTime mediante una vista
de la tabla subscriber.
* En los teléfonos SIP, configuro OpenSER como registrar, pero
Asterisk como outbound proxy.
Hasta aquí, los usuarios se registrarían en OpenSER, pero harían las
llamadas a través de Asterisk.
Ahora, la duda que tengo es un poco en el concepto de outbound proxy.
Si lo indico en los teléfonos significa que mandan TODA la
señalización a ese outbound proxy? Por ejemplo, a donde mandarían los
PUBLISH/SUBSCRIBE y los MESSAGE?
Thnx!
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
Hola, estaba pensando en pedir auth para los re-INVITE (poner en espera) en un
OpenSer que hablaría directamente con un gateway PSTN.
¿Por qué? bueno, por mero histerismo. Ya sé que un INVITE con to_tag aleatorio
llegaría al gateway y sería descartado por no existir un diálogo asociado,
pero... ¿sería muy grave si pido auth en ese re-INVITE? Más que nada porque
así me aseguro de que sólo llega al gateway INVITE's autenticados, ACK, BYE,
PRACK y OPTIONS.
¿Algún UAC que no envíe auth si se le solicita en un re-INVITE?
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Estimados amigos del foro,
Anteriormente había tenido problemas en hacer un forward desde SER a
Asterisk, este
tema ya quedo resuelto.
El problema que estoy teniendo ahora es el siguiente, detallo la
estructura de mi red.
cliente sip-------internet------OpenSER------Internet-----Asterisk-----
LAN
El efectuar una llamada desde cliente sip que esta en internet con
una ip publica hacia
un cliente sip que esta en la lan, esto funciona perfecto, en este
caso el cliente
esta registrado en OpenSer; ahora cuando un cliente de la lan que esta
registrado
en Asterisk quiere llamar a un cliente que esta registrado en open ser
tengo problemas
de loop, porque el INVITE de open ser hay un rewritehostport("xxx.xxx.
xxx.xxx:5060");
al Asterisk.
La pregunta es como puedo llamar de mi Asterisk a clientes que estan
registrados en Open
Ser.
Detallo config de OpenSER
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
exit;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER") record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
exit;
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
route(1);
exit;
};
if (is_method("INVITE")) {
#record_route(); ##
#force_rtp_proxy(); ##
rewritehostport("xxx.xxx.xxx.xxx:5060");
#t_on_reply("1"); ##
t_relay();
return;
#exit;
}
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# digest authentication
if (!www_authorize("", "subscriber")) {
www_challenge("", "0");
exit;
};
save("location");
exit;
};
lookup("aliases");
if (!uri==myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
exit;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
exit;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
Saludos,
Hola a todos,
Alguien sabe porqué cuando el llamante cuelga antes de que responda el
llamado, el teléfono del llamado sigue repicando??? y cómo se resuelve?
Un saludo
David
Estimados amigos,
Estoy de acuerdo que soluciono el problema de las llamadas desde
Asterisk a los usuarios que estan registrados en OpenSer con la función
lookup("location").
Pero si quiero llamar con un usuario registrado en OpenSer a Asterisk
tengo
que verificar si la uri no viene con la ip de asterisk hago un
rewritehostport("xxx.xxx.
> > xxx.xxx:5060")? esto en INVITE es correcto?
Saludos y gracias en lo que me puedan ayudar.
El Jueves, 24 de Enero de 2008, andresdb(a)adinet.com.uy escribió:
> > El efectuar una llamada desde cliente sip que esta en internet
con
> > una ip publica hacia
> > un cliente sip que esta en la lan, esto funciona perfecto, en este
> > caso el cliente
> > esta registrado en OpenSer; ahora
> > cuando un cliente de la lan que esta registrado
> > en Asterisk quiere llamar a un cliente que esta registrado en open
ser
> > tengo problemas
> > de loop, porque el INVITE de open ser hay un rewritehostport("xxx.
xxx.
> > xxx.xxx:5060"); al Asterisk.
Piensa que Asterisk es un B2BUA, así que NO es el cliente LAN
registrado en
Asterisk el que llama al cliente registrado en OpenSer, es ASTERISK el
que
llama a ese cliente de OpenSer (y OpenSer sólo ruta la llamada).
Ahora, si cuando OpenSer recibe ese INVITE desde **ASTERISK** hace un:
rewritehostport("IP_ASTERISK:5060")
entonces ocurrirá un loop que Asterisk no sabe detectar. Pero sobre
todo, ¿por
qué **** haces ese "rewritehostport"? es un error tuyo. Si quieres que
ese
INVITE desde Asterisk llegue al usuario registrado en OpenSer ¿por qué
no
haces un lookup("location")?
-- Iñaki Baz Castillo _______________________________________________
Users-es mailing list Users-es(a)lists.openser.org http://lists.openser.
org/cgi-bin/mailman/listinfo/users-es
Hola a todos,
Estoy pensando en montar una solución muy grande, pero no sé muy bien
cómo hacerlo. Os explico:
Quitero montar un array balanceado con rrDNS. Pero no sé como se hace eso!!
lo de 2 openser apuntando al mismo MySQL, etc, está claro...
pero, ¿¿si un cliente está registrado en uno y llama a uno que está
registrado en otro??
UN saludo
David
Hola,
¿Cómo evitar el "Loop Detected"?
A veces necesito mandar llamadas de un usuario local a un usuario local a
través de un asterisk, y el asterisk tiene que devolver la llamada al
openser... de ahí el "Loop Detected"... pero lo hago a sabiendas...
¿Cómo se puede evitar el Loop check?
saludos