Seria Bueno ver los mensajes SIP anteriores para ver en que momento se pierde la comunicación. Parecería que uno de los UA no se da cuenta que el otro se desconecto.
Hola a todos. Estoy haciendo unas pruebas de stress en un asterisk instalado en un servidor potente con la intención de ver cuantas llamadas es capaz de aguantar (bueno eso ya os lo imaginabais :).
El caso es que en el SIPp client cuando el flujo de Audio de la primera llamada enviada finaliza, el BYE se envía una y otra vez, no para de restransmitirse...No he mirado si a las siguientes llamadas le sucede lo mismo pero estoy seguro que sí porque al finalizar la pruebas tengo mucho mas reenvios de BYE que llamadas propiamente.
Cuando empieza a fallar la carga tanto del servidor como del cliente no llega ni al 50% por lo que no es problema de recursos de CPU ni de memoría.
Despues miro en lo logs de SIPp y me encuentro con estos errores, que se repiten con frecuencia:
2008-09-29 18:31:18:269 1222705878.269500: Continuing call on unexpected message for Call-Id '3-2320(a)192.168.1.140': while expecting '200' (index 10), received 'SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 192.168.1.140:5060;branch=z9hG4bK-2320-3-9;received=192.168.1.140
From: sipp <sip:sipp@192.168.1.140:5060>;tag=2320SIPpTag003
To: sut <sip:9876543210@192.168.1.246:5060>;tag=as407f5326
Call-ID: 3-2320(a)192.168.1.140
CSeq: 2 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
2008-09-29 18:31:18:642 1222705878.642500: Continuing call on unexpected message for Call-Id '17-2320(a)192.168.1.140': while expecting '200' (index 10), received 'SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 192.168.1.140:5060;branch=z9hG4bK-2320-17-9;received=192.168.1.140
From: sipp <sip:sipp@192.168.1.140:5060>;tag=2320SIPpTag0017
To: sut <sip:9876543210@192.168.1.246:5060>;tag=as77779841
Call-ID: 17-2320(a)192.168.1.140
CSeq: 2 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
Hay a millones...
Por lo que me he podido informar es un problema de que el destinatario de la llamada ha colgado y un NOTIFY no ha informado a al origen, por tanto el origen al enviar el BYE se encuentra con el problema. En principio creo que este no es el problema, porque en el escenario que uso en el SIPpSERVER no cuelga, es siempre el SIPpCLIENTE el que lo hace.
También he visto que puede haber un problema con los tags del From, To, pero no lo he llegado a entender del todo bien. He visto que con este tema al parecer hay un patch para Asterisk (que por cierto la versión que estoy utilizando es la 1.4.21.2).
La pena es que no encuentro ahora la Web con el bug. Cuando la encuentre os la hago saber.
Espero que podais ayudarme porque tal vez conozcais este error de antemano. Muchas gracias :)
_________________________________________________________________
Llega la nueva temporada. Consulta las nuevas tendencias en MSN Estilo
http://estilo.es.msn.com/moda/
_______________________________________________
Users-es mailing list
Users-es(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es
Hola a todos. Estoy haciendo unas pruebas de stress en un asterisk instalado en un servidor potente con la intención de ver cuantas llamadas es capaz de aguantar (bueno eso ya os lo imaginabais :).
El caso es que en el SIPp client cuando el flujo de Audio de la primera llamada enviada finaliza, el BYE se envía una y otra vez, no para de restransmitirse...No he mirado si a las siguientes llamadas le sucede lo mismo pero estoy seguro que sí porque al finalizar la pruebas tengo mucho mas reenvios de BYE que llamadas propiamente.
Cuando empieza a fallar la carga tanto del servidor como del cliente no llega ni al 50% por lo que no es problema de recursos de CPU ni de memoría.
Despues miro en lo logs de SIPp y me encuentro con estos errores, que se repiten con frecuencia:
2008-09-29 18:31:18:269 1222705878.269500: Continuing call on unexpected message for Call-Id '3-2320(a)192.168.1.140': while expecting '200' (index 10), received 'SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 192.168.1.140:5060;branch=z9hG4bK-2320-3-9;received=192.168.1.140
From: sipp <sip:sipp@192.168.1.140:5060>;tag=2320SIPpTag003
To: sut <sip:9876543210@192.168.1.246:5060>;tag=as407f5326
Call-ID: 3-2320(a)192.168.1.140
CSeq: 2 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
2008-09-29 18:31:18:642 1222705878.642500: Continuing call on unexpected message for Call-Id '17-2320(a)192.168.1.140': while expecting '200' (index 10), received 'SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 192.168.1.140:5060;branch=z9hG4bK-2320-17-9;received=192.168.1.140
From: sipp <sip:sipp@192.168.1.140:5060>;tag=2320SIPpTag0017
To: sut <sip:9876543210@192.168.1.246:5060>;tag=as77779841
Call-ID: 17-2320(a)192.168.1.140
CSeq: 2 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
Hay a millones...
Por lo que me he podido informar es un problema de que el destinatario de la llamada ha colgado y un NOTIFY no ha informado a al origen, por tanto el origen al enviar el BYE se encuentra con el problema. En principio creo que este no es el problema, porque en el escenario que uso en el SIPpSERVER no cuelga, es siempre el SIPpCLIENTE el que lo hace.
También he visto que puede haber un problema con los tags del From, To, pero no lo he llegado a entender del todo bien. He visto que con este tema al parecer hay un patch para Asterisk (que por cierto la versión que estoy utilizando es la 1.4.21.2).
La pena es que no encuentro ahora la Web con el bug. Cuando la encuentre os la hago saber.
Espero que podais ayudarme porque tal vez conozcais este error de antemano. Muchas gracias :)
_________________________________________________________________
Llega la nueva temporada. Consulta las nuevas tendencias en MSN Estilo
http://estilo.es.msn.com/moda/
