sr-users-es

sr-users-es@lists.kamailio.org

487 discussions

[Kamailio-Users-ES] Dos Tarjetas de Red y 404 Notfound de Kamailio a Asterisk

by ingdavidcespedes＠cable.net.co

Hola Lista! Tengo el siguiente escenario todas las direcciones son 192.168.x.x UA(EXT:4000,IP:3.10:5061)<--->Kamailio(IP:.3.10:5060)<--->(IP:.3.1)Router(IP:.2.2)<--->(IP:.2.1)Router(.1.1)<--->(IP:.1.10:5060)Asterisk<--->UA(EXT:1000,IP:.1.10:5061) El Servidor Asterisk tiene dos tarjetas de red (eth0=10.2.7.12 y eth1=192.168.1.10). Por la eth0 me estoy conectando al proveedor IP que me da salida a la PSTN y por la eth1 tengo la conexión interna al kamailio. Por ahora solo estoy tratando de que llegue una llamada desde un usuario en el PC con kamailio (4000(a)192.168.3.10) hasta un usuario en el PC con asterisk (1000(a)192.168.1.10). Pero aquí tengo dos problemas: 1 Una vez llega el INVITE al asterisk, este responde que un 404 Not found, aun cuando este usuario exite en todos los context que tengo 2 Esta respuesta 404 Not found la envía por la interfaz eth0(10.2.7.12) y no por la eth1(192.168.1.10) que fue por donde llego el invite, lo que hace que el kamailio al otro lado, nunca escuche la respuesta 404 y siga reenviando el invite hasta que se cumple el tiempo y manda un sessiontimeout. ¿Como puedo hacer para que las invitaciones que reciba por la eth0 las responda por la eth0 y las que reciba por la eth1 las responda por la eth1(en este momento cualquier cosa que llega, sin importar de donde, trata de responderla por la eth0), pues este problema también me esta afectando las llamadas, pues si registro la ext1000 con la interfaz eth0 logro que me oigan y ser oído en las llamadas hacia la PSTN pero no internas, y sucede lo contrario si registro la ext1000 en la interfaz eth1? ¿Que puede estar pasando para que asterisk no encuentre el usuario y devuelva el 404 Not found? En el X-lite estoy marcando literalmente 1000(a)192.168.1.10. Agradezco sus comentarios David Céspedes Esta es la traza de la llamada vista desde el PC asterisk ngrep -d any -P ' ' -W byline -T port 5060 U +0.536344 192.168.3.10:5060 -> 192.168.1.10:5060 INVITE sip:1000@192.168.1.10 SIP/2.0 Record-Route: <sip:192.168.3.10;lr=on> Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcc67.50486f36.0 Via: SIP/2.0/UDP 192.168.3.10:5061;rport=5061;branch=z9hG4bK0EB39999C3439B5CA2A6474246F1222E From: 4000 <sip:4000@192.168.3.10:5061>;tag=887353323 To: <sip:1000@192.168.1.10> Contact: <sip:4000@192.168.3.10:5061> Call-ID: 5CC44063-EC9C-54B3-D53C-CADAA13AE074(a)192.168.3.10 CSeq: 6181 INVITE Max-Forwards: 69 Content-Type: application/sdp User-Agent: X-Lite release 1105d Content-Length: 307 P-hint: outbound v=0 o=4000 743050123 743050177 IN IP4 192.168.3.10 s=X-Lite c=IN IP4 192.168.3.10 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv # U +0.534858 10.2.7.12:5060 -> 192.168.3.10:5060 SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.3.10;branch=z9hG4bKcc67.50486f36.0;received=192.168.3.10 Via: SIP/2.0/UDP 192.168.3.10:5061;rport=5061;branch=z9hG4bK0EB39999C3439B5CA2A6474246F1222E From: 4000 <sip:4000@192.168.3.10:5061>;tag=887353323 To: <sip:1000@192.168.1.10>;tag=as3ac5e39d Call-ID: 5CC44063-EC9C-54B3-D53C-CADAA13AE074(a)192.168.3.10 CSeq: 6181 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0

16 years

Re: [Kamailio-Users-ES] dudas integración realtime con openser

by ingdavidcespedes＠cable.net.co

Gracias por la respuesta, esto quiere decir que ya no habría necesidad del sip.conf (o acaso del extensions.conf) por que este se crearía a partir de la base de datos? ----- Mensaje original ----- De: Saúl Ibarra <saghul(a)gmail.com> Fecha: Martes, Octubre 14, 2008 10:10 am Asunto: Re: [Kamailio-Users-ES] dudas integración realtime con openser > RealTime es una forma de almacenar la configuración de Asterisk, de > manera que la lee de una BBDD. > > > -- > Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de > disketes."---------------------------------------------------------- > ------ > http://www.saghul.net/ > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

16 years

[Kamailio-Users-ES] Facturar llamadas Sip-to-SIP locales con asterisk/a2billing

by Rafael Risco Gonzales-Vigil

Hola Tengo en produccion openser/kamailio integrado a asterisk que uso como gw a pstn y de paso con a2billing para facturar las llamadas entrantes y salientes de la pstn, todo funciona perfecto pero ahora necesito facturar las llamadas sip-to-sip, algo asi como usar asterisk/a2biling como b2bua para facturar como pre o postpago las llamadas locales. Como veran abajo solo intente rewritehostport("192.168.12.254:5070") y luego route(3) pero no funciona, la llamada simplemente se completa sin pasar por asterisk. luego intente agregando apend_branch() y en ese caso la llamda si se direcciona a asterisk pero se corta y en a2billing veo el cdr como 'congestion', lo mismo si uso t_relay(192.168.12.254:5070)... Si alguien logro este escenario por favor envienme alguna recomendacion, saludos, rafael Lima . Peru ######################################################################## # Request route 'INVITE-to-INTERNAL' ######################################################################## route[6] { # Aqui cortamos las llamadas que vienen del Gateway-pstn (marcados con flag 23) a clientes no registrados: if(!lookup("location") && isflagset(23)) { xlog("L_INFO", "\n404 - User Not Found: CALL FROM PSTN F=$fu TO OFFLINE LOCAL USER T=$tu \n\n"); sl_send_reply("404", "User Not Found"); exit; }; # Aqui progresamos llamadas que vienen del GW a #s registrados: if(lookup("location") && isflagset(23)) { xlog("L_INFO", "Local user online: CALL FROM PSTN F=$fu TO ONLINE LOCAL USER T=$tu \n\n"); route(3); # To Request route 'BASE-OUTBOUND' section exit; }; # Por defecto en esta seccion procesamos las llamadas que se originan en clientes registrados a este sip server: # Si callee no esta registrado enviar a GW AS5350 para buscar en el el dominio H323 if(!lookup("location")) { xlog("L_INFO", "\n\nLocal user offline, sending to route[7] to check if its a H.323 UA in Vsat Network - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n\n"); route(7); # Request route 'INVITE-to-EXTERNAL' or 'INVITE-to-A2B' }; ### Aca procesamos llamadas a numeros registrados en kamailio desde otros clientes locales: if(lookup("location")) { xlog("L_INFO", "\n\n\nCall to On-Line Local user: SIP-to-SIP to - A2B - M=$rm RURI=$ru F=$fu \n"); # rewritehostport("192.168.12.254:5070"); para enviar a a2billing ...no funciona. # append_branch(); ## ---- porque???? route(3); }; exit; }

16 years

[Kamailio-Users-ES] dudas integración realtime con openser

by troxlinux

señores estoy integrando mi openser con asterisk realtime pues ya realice todos los pasos de asterisk para el realtime, la idea es conseguir la lucecita del voicemail , veo dentro de la base de datos de asterisk la replicacion de los usuarios de la tabla subscriber de openser todo bien aqui , lo que si me parece extraño ahora es que todas la funcionalidades que tengo con el asterisk como media server no me trabajan al 100% como las tenia antes ,por ejemplo antes cuando no contestaba me saltaba al voicemail y al integrar el realtime con asterisk me tira este error : chan_sip.c:5095 process_sdp: Unable to lookup host in c= line, 'IN IP4 192.168.1.64192.168.1.64' lo extraño es que esa ip en log de asterisk es la ip que vieve del dsl y no por la interfaz lan que es donde registro mis usuarios .. algo que me este faltando del realtime? .. saludos lista rickygm ### sip debug asterisk #### --- (18 headers 24 lines) --- Sending to 192.168.10.1 : 5060 (NAT) Using INVITE request as basis request - e3b32187ee145e96(a)192.168.10.28 Found user '119' [Oct 13 23:30:23] WARNING[9912]: chan_sip.c:5095 process_sdp: Unable to lookup host in c= line, 'IN IP4 192.168.1.64192.168.1.64' <--- Reliably Transmitting (NAT) to 192.168.10.1:5060 ---> SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK91af.827e4ad4.1;received= 192.168.10.1 Via: SIP/2.0/UDP 192.168.10.28:5060 ;rport=5060;branch=z9hG4bK1a8140c1b66271b0 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=7dc2f363e7b65552 To: <sip:114@192.168.10.1 <sip%3A114(a)192.168.10.1>>;tag=as5a93f32a Call-ID: e3b32187ee145e96(a)192.168.10.28 CSeq: 25247 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 <------------> Scheduling destruction of SIP dialog 'e3b32187ee145e96(a)192.168.10.28' in 32000 ms (Method: INVITE) xserver*CLI> <--- SIP read from 192.168.10.1:5060 ---> ACK sip:u114@192.168.10.1:5070 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK91af.827e4ad4.1 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=7dc2f363e7b65552 Call-ID: e3b32187ee145e96(a)192.168.10.28 To: <sip:114@192.168.10.1 <sip%3A114(a)192.168.10.1>>;tag=as5a93f32a CSeq: 25247 ACK Max-Forwards: 70 User-Agent: OpenSER ### mi log sip Openser #### U +1.244159 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bKb7a454e6f1909ec6 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=d096ebe220002321 To: <sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1>>;tag=as0cd8584b Call-ID: 3bb16f05ffa03a24(a)192.168.10.28 CSeq: 30320 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 # U +0.172349 192.168.10.28:5060 -> 192.168.10.1:5060 INVITE sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1> SIP/2.0 Via: SIP/2.0/UDP 192.168.10.28:5060;branch=z9hG4bKf306872728753147 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=45d17c11e5a1f791 To: <sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1>> Contact: <sip:119@192.168.10.28:5060> Supported: replaces, timer, path Call-ID: 3bd1333498b35042(a)192.168.10.28 CSeq: 26761 INVITE User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Type: application/sdp Content-Length: 545 v=0 o=119 8000 8000 IN IP4 192.168.10.28 s=SIP Call c=IN IP4 192.168.10.28 t=0 0 m=audio 5004 RTP/AVP 0 18 4 3 2 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:3 GSM/8000 a=rtpmap:2 G726-32/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 5006 RTP/AVP 99 34 a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=428014; packetization-mode=0; sprop-parameter-sets=Z0KADJWgUH5A,aM4BryA= a=rtpmap:34 H263/90000 a=fmtp:34 CIF=2 MaxBR=1280 a=framerate:20 # U +0.000232 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.10.28:5060;branch=z9hG4bKf306872728753147;rport=5060 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=45d17c11e5a1f791 To: <sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1>>;tag=329cfeaa6ded039da25ff8cbb8668bd2.4555 Call-ID: 3bd1333498b35042(a)192.168.10.28 CSeq: 26761 INVITE Proxy-Authenticate: Digest realm="192.168.10.1", nonce="48f427bd23837102189868c302984a0314f3ac5e" Server: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.001676 192.168.10.28:5060 -> 192.168.10.1:5060 ACK sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1> SIP/2.0 Via: SIP/2.0/UDP 192.168.10.28:5060;branch=z9hG4bKf306872728753147 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=45d17c11e5a1f791 To: <sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1>>;tag=329cfeaa6ded039da25ff8cbb8668bd2.4555 Contact: <sip:119@192.168.10.28:5060> Call-ID: 3bd1333498b35042(a)192.168.10.28 CSeq: 26761 ACK User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Length: 0 # U +0.001321 192.168.10.28:5060 -> 192.168.10.1:5060 INVITE sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1> SIP/2.0 Via: SIP/2.0/UDP 192.168.10.28:5060;branch=z9hG4bK5bb5e1738e335481 From: <sip:119@192.168.10.1 <sip%3A119(a)192.168.10.1>>;tag=45d17c11e5a1f791 To: <sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1>> Contact: <sip:119@192.168.10.28:5060> Supported: replaces, timer, path Proxy-Authorization: Digest username="119", realm="192.168.10.1", algorithm=MD5, uri="sip:111@192.168.10.1 <sip%3A111(a)192.168.10.1>", nonce="48f427bd23837102189868c302984a0314f3ac5e", response="d5d20ad6310dea0460b3f4ca8b020e27" Call-ID: 3bd1333498b35042(a)192.168.10.28 CSeq: 26762 INVITE User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Type: application/sdp Content-Length: 545 v=0 o=119 8000 8001 IN IP4 192.168.10.28 s=SIP Call c=IN IP4 192.168.10.28 t=0 0 m=audio 5004 RTP/AVP 0 18 4 3 2 101 a=sendrecv a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:3 GSM/8000 a=rtpmap:2 G726-32/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 5006 RTP/AVP 99 34 a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=428014; packetization-mode=0; sprop-parameter-sets=Z0KADJWgUH5A,aM4BryA= a=rtpmap:34 H263/90000 a=fmtp:34 CIF=2 MaxBR=1280 a=framerate:20

16 years

Re: [Kamailio-Users-ES] Crear una transacción antes de autenticar, ¿sí o no?

by ingdavidcespedes＠cable.net.co

Mmmmm creo que en la recomendaciones SIP Connect también dicen que no se cree una nueva transacción hasta que no se haya autenticado. De pronto se podría crear alguna forma para que este primer request no fuera stateless "Nuevo RFC {:-)} ", pero por el momento me quedo con la forma recomendada por el RFC. ----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Lunes, Octubre 13, 2008 8:21 am Asunto: Re: [Kamailio-Users-ES] Crear una transacción antes de autenticar, ¿sí o no? > El día 13 de octubre de 2008 15:04, Raúl Alexis Betancor Santana > <rabs(a)dimension-virtual.com> escribió: > > On Monday 13 October 2008 12:46:23 Iñaki Baz Castillo wrote: > >> Esto último es negativo pues cuanto más se estrese al servidor de > >> autenticación (LDAP o lo que sea) peor. Yo creo que en un escenario > >> así (donde la autenticación toma tiempo) sí que puede ser bueno > crear>> la transacción justo antes del proceso de autenticación > (eso sí, sólo > >> para requests que contengan la cabecera "(Proxy-)Authorization". > > > > Es que aún estoy intentando averiguar quien demonios puede tener > un escenario > > en producción donde la respuesta del sistema de autentitación > tarde tanto que > > provoque una retrasmisión del request por parte del UAC. > > Bueno, la primera retransmisión es a los T1 segundos (0,5 segundos), > tampoco es tanto. A nada que el LDAP sea "muy" remoto o haya carga (en > la conexión al LDAP me refiero)... > > > > A parte de que ¿en que otras situaciones puede ser útil?, no veo > muchos> escenarios en los que pueda ser útil esa técnica anti-RFC > > Bueno, no es anti-RFC. El 3261 simplemente aconseja no crear la > transacción hasta haber autenticado el request, pero no es un MUST ni > mucho menos. > > > -- > Iñaki Baz Castillo > <ibc(a)aliax.net> > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

16 years

Re: [Kamailio-Users-ES] dudas integración realtime con openser

by ingdavidcespedes＠cable.net.co

:-( ¿Realtime Time es que asterisk y kamailio accedan a la misma base de datos al mismo tiempo? ¿Que es real time? :-( ----- Mensaje original ----- De: Saúl Ibarra <saghul(a)gmail.com> Fecha: Martes, Octubre 14, 2008 1:43 am Asunto: Re: [Kamailio-Users-ES] dudas integración realtime con openser > Como has hecho la vista de la tabla subscriber? Yo tuve más de un > problema con eso... > > > -- > Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de > disketes."---------------------------------------------------------- > ------ > http://www.saghul.net/ > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

16 years

[Kamailio-Users-ES] Crear una transacción antes de autenticar, ¿sí o no?

by Iñaki Baz Castillo

Hola, el RFC 3261 dice, en alguna parte que no recuerdo, que es aconsejable que un proxy/server no cree una transacción hasta que no se haya autenticado el request (si procede). El argumento es que una transacción consume recursos y que un atacante malicioso podría enviar una burrada de requests en paralelo para saturar el proxy/server. Es decir: 1 - Llega un request (req1). 2 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateless, con un 401/407. 3 - El UAC repite el request con autenticación (req2). 4 - El proxy lo recibe y calcula el digest y tal y da por buena la autenticación. 5 - Entonces el proxy crea la transacción. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción). Pero en un hilo en la lista de OpenSIPS, Bogdan me comenta que crear la transacción antes de autenticar puede ser positivo ya que evita el proceso de autenticación en retransmissiones del request. Es decir: 1 - Llega un request (req1). 2 - El proxy crea la transacción. 3 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateful, con un 401/407. 4 - El UAC repite el request con autenticación (req2). 5 - El proxy lo recibe y se pone a calcular el digest, pero le lleva un rato. 6 - Llega una retransmisión de req2 y como ya existe la transacción no se procesa de nuevo la autenticación (BIEN). 7 - El proxy da por buena la autenticación previa. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción). Ambas formas tienen sus inconvenientes, ¿cuál creéis que es mejor? Saludos. -- Iñaki Baz Castillo <ibc(a)aliax.net>

16 years

Re: [Kamailio-Users-ES] Realtime Integration Asterisk Kamailio

by ingdavidcespedes＠cable.net.co

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Jueves, Octubre 9, 2008 4:05 pm Asunto: Re: [Kamailio-Users-ES] Realtime Integration Asterisk Kamailio > El Jueves, 9 de Octubre de 2008, ingdavidcespedes(a)cable.net.co > escribió:> Hola lista > > > > Alguien me puede explicar a que se refiere la integración real > time entre > > asterisk y Kamailio? Yo estoy integrando kamailio con asterisk > para usarlo > > como Gateway y poder autenticarme ante mi proveedor SIP con > nombre de > > Usuario y contraseña, para esto me estoy basando en la guía de > Sahul Ibarra > > (http://www.saghul.net/blog/2007/08/17/howto-conexion-de-openser- > con-asteri > >sk/) pero no se si esto es real tieme o que es real time en > realidad???.> > > Otra duda. Los usuarios deben estar registrados en Kamailio > solamente o en > > Asterisk solamente o en ambos?? > > Integración OpenSer + Asterisk suele implicar que ambos "comparten" > la misma > base de datos de usuarios. Lo normal, creo que suele ser poner un > OpenSer > delante del Asterisk, de tal forma que OpenSer maneja y registra > los usuarios > SIP, y Asterisk tiene una vista SQL que ataca a la tabla de > "subscribers" de > OpenSer (hay manuales y howtos al respecto). > Una vez vi que Sahul decía que los usuarios no se debían registrar en Asterisk sino solo en Kamailio, y que asterisk actuara solo para los servicios que no puede prestar kamailio, como IVR, Voicemail, GW, etc. Según esto no necesito que asterisk tenga acceso a mi Base de Datos de Kamailio en MySQL si solo lo voy a usar como IVR y/o GateWay. ¿No? Pero pues en la guía que esta en la pagina de Kamailio (http://www.kamailio.org/dokuwiki/doku.php/asterisk:realtime-integration) lo configuran de tal manera que ambos acceden a la misma base de datos, generando una copia de la de Kamailio para que acceda Asterisk. He ahí mi confusión, no se si eso es por el tal real time (que sigo sin saber que es) o si siempre debe ser de esa forma, o de la forma como creí que decía Sahul. > > -- > Iñaki Baz Castillo > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

16 years, 1 month

[Kamailio-Users-ES] Realtime Integration Asterisk Kamailio

by ingdavidcespedes＠cable.net.co

Hola lista Alguien me puede explicar a que se refiere la integración real time entre asterisk y Kamailio? Yo estoy integrando kamailio con asterisk para usarlo como Gateway y poder autenticarme ante mi proveedor SIP con nombre de Usuario y contraseña, para esto me estoy basando en la guía de Sahul Ibarra (http://www.saghul.net/blog/2007/08/17/howto-conexion-de-openser-con-asteris…) pero no se si esto es real tieme o que es real time en realidad???. Otra duda. Los usuarios deben estar registrados en Kamailio solamente o en Asterisk solamente o en ambos?? Saludos David Céspedes

16 years, 1 month

Re: [Kamailio-Users-ES] Conexion de 2 Kamailio con TLS

by ingdavidcespedes＠cable.net.co

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Viernes, Octubre 3, 2008 6:10 pm Asunto: Re: [Kamailio-Users-ES] Conexion de 2 Kamailio con TLS > El Sábado, 4 de Octubre de 2008, ingdavidcespedes(a)cable.net.co > escribió:> Gracias Iñaki, basado en esto lo haré con asterisk, pues > como ya les he > > comentado, estoy haciendo la tesis sobre las recomendaciones > técnicas de > > SIP Connect, y debo tratar de cumplir con todos los RFC's que > allí enuncian > > sobre todo el de SIP 3261. Entonces no me sirve que me salga de > chiripa,> creo que con asterisk sera más claro el intercambio de > mensajes SIP entre > > las diferentes entidades. > > Sí, pero ten también en cuenta que Asterisk es bastante "cerdo" > como B2BUA > (tema de re-INVITE y tal). > Por eso te sugería que podrías usar un B2BUA más "puro" (aunque no > sabría > decirte cual). > El problema es $$$ y recursos, no cuento con muchos equipos como para escoger. Y también tiempo, tengo que terminar antes de diciembre. El escenario pensado es: Proveedor(Quien me da salida a la PSTN)<---------->Misma Maquina(Asterisk(Como Gateway SIP)<---->Kamilio(SPS))<----ComunicaciónTLSentrelosSPS---->Misma Maquina(Kamilio(SPS)<---->Asterisk(Para IVR y Voicemail)) No se que comentarios tengan acerca de este escenario. En este momento me falta conectar los 2 Kamailio vía TLS, que ya leí como se hace pero todavía no lo he hecho, y después mirar de que manera enruto las llamadas para que lleguen hasta la PSTN, si a travez de Asterisk(Como Gateway SIP) o de que otra forma (kamailio con modulo UAC). Bienvenidos sus comentarios. > -- > Iñaki Baz Castillo > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

16 years, 1 month

← Newer
1
...
15
16
17
18
19
20
21
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es