sr-users-es October 2008

sr-users-es@lists.kamailio.org

9 participants
22 discussions

[OpenSER-Users-ES] Integracion openser + alcatel

by Mariam M. T.

En primer lugar agradecer a David Villasmil por la sugerencia en la anterior consulta, teneis razon era cuestiones de alcance en las VLANs y permisos en el Firewall. ya me funciona. Ahora mi consulta es: Resulta que en esta empresa se tiene implementado telefonia IP, con equipos y software propietario de Alcatel, por cierto me dicen que les costo mucho dinero, por cuestiones de licencia no tiene permisos para utiizar softphones, solo telefonos IP, en tal sentido la idea mia es integrar mi openser con el sistema propietario, para que mis usuarios pueden hacer llamadas a los usuarios en el sistema propietario y viciversa. Aunque encontre un pequeño problema, ya que el sistema propietario funciona con el protocolo H.323, entonces, sera posible integrar dos sistemas que funcionan con diferentes protocolos como openser y alcatel, y si es posible que es lo que necesito para integrar Openser con Alcatel. Gracias de antemano por las sugerencias Saludos _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=…

15 years, 10 months

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

by ingdavidcespedes＠cable.net.co

----- Mensaje original ----- De: Raúl Alexis Betancor Santana <rabs(a)dimension-virtual.com> Fecha: Domingo, Octubre 26, 2008 5:49 am Asunto: Re: [Kamailio-Users-ES] Dos Tarjetas de Red y 404 Notfound de Kamailio a Asterisk > ingdavidcespedes(a)cable.net.co wrote: > > > > No me gusta mucho esto de matar moscas a cañonazos, pero si no > hay mas que hacer. Aunque no se si realmente sea un error de > Asterisk, o de configuración en las tarjetas de red que hace que > cualquier cosa que llegue, no importa que sea me la responda > únicamente por la eth0. Habra una forma de indicarle en el sistema > operativo que cada tarjeta responde por lo suyo a no se que se le > de una orden diferente. Lo digo por que con Nettools cuando trato > de hacer un trace hacia la maquina de kamailio 193.168.3.10 trata > de sacarlo por la eth0 10.2.7.12 y no por la eth1 192.168.1.10 que > es la que tiene la conexión hacia esa maquina. Igual cuando hago un > ping, tengo que poner ping 192.168.3.10 -I eth1 para que llegue, si > no se pierde. > > > > :-( Yo se que esto no se debería preguntar en esta lista pero de > pronto alguien me puede ayudar. > > > No te comas la cabeza con ese tema, Asterisk JAMÁS ha funcionando > en > entornos multihoming, la única forma de que funcione "medianamente" > bien > el ese tipo de escenarios es jugar con los valores de localnet, nat > y > externip del sip.conf > > Saludos > ¿Entonces este comportamiento si es debido a una falla en asterisk y no que me falte configurar algo en mis interfaces de red?¿Indagare mas sobre localnet y externip pues no los había escuchado antes?. Gracias por la pronta respuesta. Por otro lado tenia algunos problemas cuando registraba mis softphone en alguna de las dos interfaces, no podía oír el sonido de las llamadas que me llegaban por la otra interfaz, aunque la llamada si entraba, pensé que se debía también a este problema (el de las intrefaces), pero cambie de soft, (de Xlite2.0 a Zoiper) y ahora si me funciona perfecto. Creo que ese Xlite tiene varios bugs en su versión 2.0. > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

15 years, 11 months

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

by ingdavidcespedes＠cable.net.co

> Esto es un problema de configuración de Asterisk, no de Kamailio. > Habilita el > debug en el CLI de Asterisk a ver de qué se queja (mira qué peer y > contexto > ha sido identificado en la llamada). > Efectivamente, era un problema de configuración de asterisk, pues no tenia creado el usuario [Kamailio] con host=192.168.3.10 en el sip.conf, y entonces no me aceptaba el invite de esta maquina. Lo que me confundió fue el 404 Not found que pensé que era que no encontraba la ext 1000 > > > 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. > > Esto es una guarrada de Asterisk total, ¿qué versión usas? Hasta > hace poco > Asterisk tenía un bug que, usando UDP, respondía a la IP indicada > en el Via > en vez de a la IP original, lo cuál es una gran cagada pero que ya > está > corregida. > > Este problema persiste entonces como el kamailio no ve que se responda a su invite, corta la llamada. Estoy usando Asterisk 1.4.22, no se si esta versión presenta esta falla. > > > > ¿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), > > Puedes matar moscas a cañonazos poniendo "nat=yes" en el SIP peer > por el que > llega el INVITE, pero esto habilita el modo comedia y demás. > No me gusta mucho esto de matar moscas a cañonazos, pero si no hay mas que hacer. Aunque no se si realmente sea un error de Asterisk, o de configuración en las tarjetas de red que hace que cualquier cosa que llegue, no importa que sea me la responda únicamente por la eth0. Habra una forma de indicarle en el sistema operativo que cada tarjeta responde por lo suyo a no se que se le de una orden diferente. Lo digo por que con Nettools cuando trato de hacer un trace hacia la maquina de kamailio 193.168.3.10 trata de sacarlo por la eth0 10.2.7.12 y no por la eth1 192.168.1.10 que es la que tiene la conexión hacia esa maquina. Igual cuando hago un ping, tengo que poner ping 192.168.3.10 -I eth1 para que llegue, si no se pierde. :-( Yo se que esto no se debería preguntar en esta lista pero de pronto alguien me puede ayudar. >

15 years, 11 months

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

by ingdavidcespedes＠cable.net.co

Corrijo > quise mirar primero si me > llegaba una llamada de extremo(Kamailio) a extremo(Asterisk) ;-). > Pero creo que me va a tocar empezar a configurar el kamailio y > probar primero entre kamailios.

15 years, 11 months

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

by ingdavidcespedes＠cable.net.co

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Viernes, Octubre 24, 2008 11:32 am Asunto: Re: [Kamailio-Users-ES] Dos Tarjetas de Red y 404 Notfound de Kamailio a Asterisk > El Viernes, 24 de Octubre de 2008, ingdavidcespedes(a)cable.net.co > escribió: > > 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 > > Esto es un problema de configuración de Asterisk, no de Kamailio. > Habilita el > debug en el CLI de Asterisk a ver de qué se queja (mira qué peer y > contexto > ha sido identificado en la llamada). > *CLI> sip show peers Name/username Host Dyn Nat ACL Port Status 5717559884 190.144.150.54 5060 Unmonitored 1001 (Unspecified) D 0 Unmonitored 1000/1000 192.168.1.10 D 5061 Unmonitored 3 sip peers [Monitored: 0 online, 0 offline Unmonitored: 2 online, 1 offline] *CLI> core set debug 9 Core debug was 0 and is now 9 *CLI> [Oct 24 12:06:31] NOTICE[21816]: chan_sip.c:14383 handle_request_invite: Call from '' to extension '1000' rejected because extension not found. REGISTER attempt 1 to 5717559884(a)sbc1.sip.telmexla.net.co Really destroying SIP dialog '37779f4c645453bf0ddbb90f110c7082(a)127.0.0.1' Method: REGISTER [Oct 24 12:06:51] WARNING[21816]: chan_sip.c:1958 retrans_pkt: Maximum retries exceeded on transmission 7E8953D2-B24B-83E1-E522-868860E10CE9(a)192.168.3.10 for seqno 40921 (Critical Response) -- See doc/sip-retransmit.txt. Really destroying SIP dialog '7E8953D2-B24B-83E1-E522-868860E10CE9(a)192.168.3.10' Method: INVITE [Oct 24 12:06:54] NOTICE[21816]: chan_sip.c:14383 handle_request_invite: Call from '' to extension '1000' rejected because extension not found. REGISTER attempt 1 to 5717559884(a)sbc1.sip.telmexla.net.co Really destroying SIP dialog '37779f4c645453bf0ddbb90f110c7082(a)127.0.0.1' Method: REGISTER [Oct 24 12:07:14] WARNING[21816]: chan_sip.c:1958 retrans_pkt: Maximum retries exceeded on transmission 7E8953D2-B24B-83E1-E522-868860E10CE9(a)192.168.3.10 for seqno 40921 (Critical Response) -- See doc/sip-retransmit.txt. Really destroying SIP dialog '7E8953D2-B24B-83E1-E522-868860E10CE9(a)192.168.3.10' Method: INVITE REGISTER attempt 1 to 5717559884(a)sbc1.sip.telmexla.net.co Really destroying SIP dialog '37779f4c645453bf0ddbb90f110c7082(a)127.0.0.1' Method: REGISTER *CLI> REGISTER attempt 1 to 5717559884(a)sbc1.sip.telmexla.net.co Really destroying SIP dialog '37779f4c645453bf0ddbb90f110c7082(a)127.0.0.1' Method: REGISTER *CLI> core set debug 0 Core debug is now OFF > > > 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. > > Esto es una guarrada de Asterisk total, ¿qué versión usas? Hasta > hace poco > Asterisk tenía un bug que, usando UDP, respondía a la IP indicada > en el Via > en vez de a la IP original, lo cuál es una gran cagada pero que ya > está > corregida. > Asterisk 1.4.22 > > > > > ¿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), > > Puedes matar moscas a cañonazos poniendo "nat=yes" en el SIP peer > por el que > llega el INVITE, pero esto habilita el modo comedia y demás. > esto lo debo hacer introduciendo el "nat=yes" por medio de kamailio cierto > > > ¿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. > > ¿Por qué cada vez que hay una pregunta que incluye Kamailio y > Asterisk el 99% > de la cuestión es en realidad sobre Asterisk? ;) > > :-( que pena iñaki, lo que pasa es que empece haciendo las pruebas hacia la pstn con este asterisk, pero la verdad es que este va ser un kamailio tambien, que usara asterisk solo como GW para registrarse ante el Proveedor SIP. La verdad el experimento real es empezar pasando una llamada entre los Kamailios, para luego habilitar TLS entre ellos y finalmente por medio de este asterisk que ya me está recibiendo llamadas de la PSTN (a travez de la troncal sip que me da mi proveedor) lograr tener salida a la PSTN desde el kamailio que está al otro extremo (192.168.3.10). Solo que me dio nostalgia dejar de recibir llamadas externas para empezar a configurar el Kamailio en este PC y quice mirar primero si me llegaba una llamada de extremo(Kamailio) a extermo(Kamailio) ;-). Pero creo que me va a tocar empezar a configurar el kamailio y probar primero entre kamailios. > > -- > Iñaki Baz Castillo > > _______________________________________________ > Users-es mailing list > Users-es(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es >

15 years, 11 months

[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

15 years, 11 months

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 >

15 years, 11 months

[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; }

15 years, 12 months

[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

15 years, 12 months

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 >

15 years, 12 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es October 2008