cuelgue de llamadas en 1.4 y sipp
86 views
Skip to first unread message
paketecuento
Oct 3, 2008, 5:12:13 AM10/3/08
to asterisk-es
hola a todos,
estamos haciendo unas pruebecillas de carga mediante sipp y asterisk.
Parece que todo va bien, pero al cabo de unos 30-40 segundos, empiezan
a colgarse llamadas
Sep 12 18:52:36 WARNING [4620]: chan_sip.c:1835 retrans_pkt: Maximum
retries exceeded on transmission 778f89593967725f0abe40eb1752504c (at)
10.10.206.53 for seqno 1620 (Critical Response)
Sep 12 18:52:36 WARNING [4620]: chan_sip.c:1835 retrans_pkt: Hanging
up call 778f89593967725f0abe40eb1752504c (at) 10.10.206.53 no reply to
our critical packet.
Buscando info por ahí, parece que tiene que ver con ACK y OK no
enviados (o que asterisk no sabe manejar).
El sistema es un sipp con la última version y otro asterisk con
1.4.21.2. Ambos están directamente unidos por cable cruzado (es un
test muy simple) y no hay problemas de fierewall ni NAT.
Hay gente que ha tenido el mismo problema, pero con CISCO
http://readlist.com/lists/lists.digium.com/asterisk-users/10/51369.html
alguna idea?
estamos haciendo unas pruebecillas de carga mediante sipp y asterisk.
Parece que todo va bien, pero al cabo de unos 30-40 segundos, empiezan
a colgarse llamadas
Sep 12 18:52:36 WARNING [4620]: chan_sip.c:1835 retrans_pkt: Maximum
retries exceeded on transmission 778f89593967725f0abe40eb1752504c (at)
10.10.206.53 for seqno 1620 (Critical Response)
Sep 12 18:52:36 WARNING [4620]: chan_sip.c:1835 retrans_pkt: Hanging
up call 778f89593967725f0abe40eb1752504c (at) 10.10.206.53 no reply to
our critical packet.
Buscando info por ahí, parece que tiene que ver con ACK y OK no
enviados (o que asterisk no sabe manejar).
El sistema es un sipp con la última version y otro asterisk con
1.4.21.2. Ambos están directamente unidos por cable cruzado (es un
test muy simple) y no hay problemas de fierewall ni NAT.
Hay gente que ha tenido el mismo problema, pero con CISCO
http://readlist.com/lists/lists.digium.com/asterisk-users/10/51369.html
alguna idea?
ZiLi0n
Oct 3, 2008, 11:19:45 AM10/3/08
to aster...@googlegroups.com
He estado analizando el tema un poco más y lo que sucede es que Asterisk cuelga la llamada indicando en el CLI> "Maximum retries exceed" e informa con un BYE al SIPpServidor destino y con un "481 error Call Leg transaction does not exit" ya que la llamada no se ha establecido de extremo a extremo.
El motivo de los "Maximum retries exceeded" es al parecer que el ACK del SIPpCliente no llega a Asterisk o no llega al SIPpServidor. Con el SIPp opción "-trace_msg" he visto los mensajes y si que veo como el ClienteSIPp envía el correspondiente ACK, pero despues también puedo ver varios "200 OK", lo que me da por pensar que el ACK quizás no ha sido recibido por Asterisk y este envía varias veces el "200 OK" para que el ClienteSIPp se lo vuelva a reenviar.
Veo una traza similar a esta en el Asterisk con "SIP DEBUG":
El caso es que en el escenario SIPpServidor el "200 OK" que este envía al SIPpCliente tiene el atributo "retrans" por lo que, en caso de que el SIPpServidor no reciba respuesta de este "200 OK", es decir el ACK, el "200 OK" va a ser de nuevo reenviado. Vamos segun la Web de SIPp dice lo siguiente de "retrans":
"A retransmission mechanism exists in UDP transport mode. To activate the retransmission mechanism, the "send" command must include the "retrans" attribute.When it is activated and a SIP message is sent and no ACK or response is received in answer to this message, the message is re-sent."
Estos son los escenarios:
SIPp Cliente (origen):
<scenario name="UAC with media">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500" start_rtd="1">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[local_ip_type] [local_ip]
t=0 0
m=audio [auto_media_port] RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11,16
]]>
- </send>
- <recv response="100" optional="true" rtd="1" start_rtd="2">
- </recv>
- <recv response="180" optional="true" rtd="2">
- </recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets -->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="200" crlf="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent. -->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- Play a pre-recorded PCAP file (RTP stream) -->
<nop>
<action>
<exec play_pcap_audio="pcap/call_g711a.pcap"/>
</action>
</nop>
<!-- Pause 3 minutes, which is approximately the duration of the -->
<!-- PCAP file -->
<pause milliseconds="180000"/>
<!-- Play an out of band DTMF '1' -->
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="1000"/>
<!-- The 'crlf' option inserts a blank line in the statistics report. -->
<send retrans="500">
<![CDATA[
BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 2 BYE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true">
</recv>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="50, 100, 200, 500, 1100, 2100, 3100, 4100, 5100, 6100, 10000"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
SIPpServidor (destino):
<scenario name="Basic UAS responder">
<!-- By adding rrs="true" (Record Route Sets), the route sets -->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv request="INVITE" crlf="true">
</recv>
<!-- The '[last_*]' keyword is replaced automatically by the -->
<!-- specified header if it was present in the last message received -->
<!-- (except if it was a retransmission). If the header was not -->
<!-- present or if no message has been received, the '[last_*]' -->
<!-- keyword is discarded, and all bytes until the end of the line -->
<!-- are also discarded. -->
<!-- -->
<!-- If the specified header was present several times in the -->
<!-- message, all occurences are concatenated (CRLF seperated) -->
<!-- to be used in place of the '[last_*]' keyword. -->
<send>
<![CDATA[
SIP/2.0 180 Ringing
[last_Via:]
[last_From:]
[last_To:];tag=[pid]SIPpTag01[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<send retrans="500">
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:];tag=[pid]SIPpTag01[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 18
a=rtpmap:18 G729/8000
]]>
</send>
<recv request="ACK"
optional="true"
rtd="true"
crlf="true">
</recv>
<recv request="BYE">
</recv>
<send>
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<!-- Keep the call open for a while in case the 200 is lost to be -->
<!-- able to retransmit it if we receive the BYE again. -->
<pause milliseconds="4000"/>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
En caso de que el ACK del cliente se pierda, si el servidor le envía repetidamente un 200 OK, ¿Porqué no le reenvíe el ACK otra vez?
Además lo que me hace gracia es que el SIPpServidor tiene la llegada del ACK como "opcional=true"....La duda que me queda es si a Asterisk le parece tambien opcional y por en enlace que ha puesto Paco todo apunta a que no, que Asterisk tiene que recibirlo oblogatoriamente.
Como última solución puedo modificar lo que comenta Paco, pero ¿Por qué no le envía el ACK otra vez?¿Tal vez el tiempo indicado en retrans es demasiado pequeño? Que pena que no pueda probar esto ahora mismo :(
¿Alguna solución? Muchas gracias :)
El motivo de los "Maximum retries exceeded" es al parecer que el ACK del SIPpCliente no llega a Asterisk o no llega al SIPpServidor. Con el SIPp opción "-trace_msg" he visto los mensajes y si que veo como el ClienteSIPp envía el correspondiente ACK, pero despues también puedo ver varios "200 OK", lo que me da por pensar que el ACK quizás no ha sido recibido por Asterisk y este envía varias veces el "200 OK" para que el ClienteSIPp se lo vuelva a reenviar.
Veo una traza similar a esta en el Asterisk con "SIP DEBUG":
[Dec 4 18:53:48] DEBUG[5379]: chan_sip.c:1210 retrans_pkt: SIP TIMER: Rescheduling
retransmission #2 (5) SIP/2.0 - 1
[Dec 4 18:53:48] DEBUG[5379]: chan_sip.c:1224 retrans_pkt: ** SIP timers: Rescheduling
retransmission 6 to 4000 ms (t1 500 ms (Retrans id #2))
[Dec 4 18:53:48] Retransmitting #5 (NAT) to 192.168.101.9:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.101.9:5060;branch=z9hG4bK-23618-1-0;received=192.168.101.9
From: sipp <sip:si...@192.168.101.9:5060>;tag=23618SIPpTag001
To: sut <sip:s...@192.168.101.247:5060>;tag=as6ac9adc3
Call-ID: 1-2...@192.168.101.9
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:s...@192.168.101.247>
Content-Type: application/sdp
Content-Length: 164
v=0
o=root 5368 5368 IN IP4 192.168.101.247
s=session
c=IN IP4 192.168.101.247
t=0 0
m=audio 14010 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
---
[Dec 4 18:53:52] DEBUG[5379]: chan_sip.c:1210 retrans_pkt: SIP TIMER: Rescheduling
retransmission #2 (6) SIP/2.0 - 1
[Dec 4 18:53:52] DEBUG[5379]: chan_sip.c:1224 retrans_pkt: ** SIP timers: Rescheduling
retransmission 7 to 4000 ms (t1 500 ms (Retrans id #2))
[Dec 4 18:53:52] Retransmitting #6 (NAT) to 192.168.101.9:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.101.9:5060;branch=z9hG4bK-23618-1-0;received=192.168.101.9
From: sipp <sip:si...@192.168.101.9:5060>;tag=23618SIPpTag001
To: sut <sip:s...@192.168.101.247:5060>;tag=as6ac9adc3
Call-ID: 1-2...@192.168.101.9
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:s...@192.168.101.247>
Content-Type: application/sdp
Content-Length: 164
v=0
o=root 5368 5368 IN IP4 192.168.101.247
s=session
c=IN IP4 192.168.101.247
t=0 0
m=audio 14010 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
[Dec 4 18:53:56] WARNING[5379]: chan_sip.c:1243 retrans_pkt: Maximum retries exceeded on
transmission 1-2...@192.168.101.9 for seqno 1 (Critical Response)
[Dec 4 18:53:56] Destroying call '1-2...@192.168.101.9'
El caso es que en el escenario SIPpServidor el "200 OK" que este envía al SIPpCliente tiene el atributo "retrans" por lo que, en caso de que el SIPpServidor no reciba respuesta de este "200 OK", es decir el ACK, el "200 OK" va a ser de nuevo reenviado. Vamos segun la Web de SIPp dice lo siguiente de "retrans":
"A retransmission mechanism exists in UDP transport mode. To activate the retransmission mechanism, the "send" command must include the "retrans" attribute.When it is activated and a SIP message is sent and no ACK or response is received in answer to this message, the message is re-sent."
Estos son los escenarios:
SIPp Cliente (origen):
<scenario name="UAC with media">
<!-- In client mode (sipp placing calls), the Call-ID MUST be -->
<!-- generated by sipp. To do so, use [call_id] keyword. -->
<send retrans="500" start_rtd="1">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[local_ip_type] [local_ip]
t=0 0
m=audio [auto_media_port] RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11,16
]]>
- </send>
- <recv response="100" optional="true" rtd="1" start_rtd="2">
- </recv>
- <recv response="180" optional="true" rtd="2">
- </recv>
<!-- By adding rrs="true" (Record Route Sets), the route sets -->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv response="200" crlf="true">
</recv>
<!-- Packet lost can be simulated in any send/recv message by -->
<!-- by adding the 'lost = "10"'. Value can be [1-100] percent. -->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<!-- Play a pre-recorded PCAP file (RTP stream) -->
<nop>
<action>
<exec play_pcap_audio="pcap/call_g711a.pcap"/>
</action>
</nop>
<!-- Pause 3 minutes, which is approximately the duration of the -->
<!-- PCAP file -->
<pause milliseconds="180000"/>
<!-- Play an out of band DTMF '1' -->
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_1.pcap"/>
</action>
</nop>
<pause milliseconds="1000"/>
<!-- The 'crlf' option inserts a blank line in the statistics report. -->
<send retrans="500">
<![CDATA[
BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 2 BYE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<recv response="200" crlf="true">
</recv>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="50, 100, 200, 500, 1100, 2100, 3100, 4100, 5100, 6100, 10000"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
SIPpServidor (destino):
<scenario name="Basic UAS responder">
<!-- By adding rrs="true" (Record Route Sets), the route sets -->
<!-- are saved and used for following messages sent. Useful to test -->
<!-- against stateful SIP proxies/B2BUAs. -->
<recv request="INVITE" crlf="true">
</recv>
<!-- The '[last_*]' keyword is replaced automatically by the -->
<!-- specified header if it was present in the last message received -->
<!-- (except if it was a retransmission). If the header was not -->
<!-- present or if no message has been received, the '[last_*]' -->
<!-- keyword is discarded, and all bytes until the end of the line -->
<!-- are also discarded. -->
<!-- -->
<!-- If the specified header was present several times in the -->
<!-- message, all occurences are concatenated (CRLF seperated) -->
<!-- to be used in place of the '[last_*]' keyword. -->
<send>
<![CDATA[
SIP/2.0 180 Ringing
[last_Via:]
[last_From:]
[last_To:];tag=[pid]SIPpTag01[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<send retrans="500">
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:];tag=[pid]SIPpTag01[call_number]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 18
a=rtpmap:18 G729/8000
]]>
</send>
<recv request="ACK"
optional="true"
rtd="true"
crlf="true">
</recv>
<recv request="BYE">
</recv>
<send>
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:[local_ip]:[local_port];transport=[transport]>
Content-Length: 0
]]>
</send>
<!-- Keep the call open for a while in case the 200 is lost to be -->
<!-- able to retransmit it if we receive the BYE again. -->
<pause milliseconds="4000"/>
<!-- definition of the response time repartition table (unit is ms) -->
<ResponseTimeRepartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-- definition of the call length repartition table (unit is ms) -->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
En caso de que el ACK del cliente se pierda, si el servidor le envía repetidamente un 200 OK, ¿Porqué no le reenvíe el ACK otra vez?
Además lo que me hace gracia es que el SIPpServidor tiene la llegada del ACK como "opcional=true"....La duda que me queda es si a Asterisk le parece tambien opcional y por en enlace que ha puesto Paco todo apunta a que no, que Asterisk tiene que recibirlo oblogatoriamente.
Como última solución puedo modificar lo que comenta Paco, pero ¿Por qué no le envía el ACK otra vez?¿Tal vez el tiempo indicado en retrans es demasiado pequeño? Que pena que no pueda probar esto ahora mismo :(
¿Alguna solución? Muchas gracias :)
Ahora llévate lo mejor de MSN y Windows Live, en tu móvil
eVeLY
Oct 5, 2008, 6:24:59 PM10/5/08
to asterisk-es
Una vez me salio un error parecido, y lo que encontre en google fue
que probablemente era un ataque por negación de servicio. Lo que tiene
sentido teniendo en cuenta que estas haciendo pruebas de carga.
que probablemente era un ataque por negación de servicio. Lo que tiene
sentido teniendo en cuenta que estas haciendo pruebas de carga.
Reply all
Reply to author
Forward
0 new messages