Problemas con la retransmisión de un request pending
joaquindk
que surge cuando trato de poner una llamada en espera (mediante el
envío de un SIP/INVITE) cuando asterisk aún está enviándome la
reconfiguración de la llamada para el envío directo de RTP entre dos
UACs. El caso es que como asterisk se encuentra tramitando el re-
INVITE pues me contesta con una response 491 Request Pending a mi
solicitud de poner la llamada en espera. Hasta ahí todo bien, yo le
contesto a Asterisk con un ACK y una vez hecha la reconfiguración
trato de poner la llamada en espera con un nuevo re-INVITE (el cual
hace bien - sin embargo no da el primero como finalizado porque sigue
reenviando la respuesta SIP 491).
El problem está en que Asterisk no se da por satisfecho al responderle
con un ACK y por lo tanto continúa retransmitiendome el Request
Pending hasta que da por finalizada la llamada. Según el rfc3261 al
recibir la respuesta request pending debería de iniciar un timer que
determine cuándo debe volver a enviarse mi INVITE...lo he hecho
enviándole tanto el mismo INVITE como uno nuevo, sin éxito, Asterisk
seguía reenviandome el primer request pending y luego finalizaba la
llamada. La respuesta que me envía asterisk es la siguiente:
SIP/2.0 491 Request Pending
Via: SIP/2.0/UDP
10.110.7.89:5070;branch=z9hG4bK5a668c33f196837c3602266b23b389e0;received=10.110.7.89
From: <sip:30001 at 10.110.7.20:5070>;tag=SIPTester
To: <sip:30008 at 10.110.7.20>;tag=as2ea72122
Call-ID: 0dd43bb5a64eb5a2fb0114193821f037 at 10.110.7.89
CSeq: 5 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
X-Asterisk-HangupCause: Normal
A lo cual yo contesto con:
ACK sip:30008 at 10.110.7.20 SIP/2.0
Call-ID: 0dd43bb5a64eb5a2fb0114193821f037 at 10.110.7.89
Max-Forwards: 70
From: <sip:30001 at 10.110.7.20:5070>;tag=SIPTester
To: <sip:30008 at 10.110.7.20>;tag=as2ea72122
Via: SIP/2.0/UDP
10.110.7.89:5070;branch=z9hG4bK5a668c33f196837c3602266b23b389e0
CSeq: 5 ACK
Content-Length: 0
Sin embargo al cabo de unos 20 segundo se produce este aviso en la
consola de Asterisk:
Aug 21 11:21:06 WARNING9686: chan_sip.c:1967 retrans_pkt: Maximum
retries exceeded on transmission
0dd43bb5a64eb5a2...@10.110.7.89 for seqno 5 (Critical
Response) — See doc/sip-retransmit.txt.
Aug 21 11:21:06 WARNING9686: chan_sip.c:1989 retrans_pkt: Hanging up
call 0dd43bb5a64eb5a2...@10.110.7.89 - no reply to our
critical packet (see doc/sip-retransmit.txt).
y se cuelga la llamada. También he intentado enviar un cancel del
INVITE pero tampoco he obtenido ningún éxito ya que asterisk ya me
había contestado con la respuesta 491 Request Pending.
¿Alguien sabe qué es lo que estoy haciendo mal? ¿Qué tengo que hacer
para que Asterisk no me reenvie el Request Pending y luego de por
finalizada la llamada?
Iñaki Baz Castillo
> Hola, estoy desarrollando un UAC y me he encontrado con un problema
> que surge cuando trato de poner una llamada en espera (mediante el
> envío de un SIP/INVITE) cuando asterisk aún está enviándome la
> reconfiguración de la llamada para el envío directo de RTP entre dos
> UACs.
Por favor detalla/corrige el siguiente flujo para que entienda bien qué es lo
que pasa:
1) UA1 lanza el primer INVITE, Asterisk envía INVITE a UA2, recibe 200 de UA2
y le envía ACK, responde 200 a UA1 y UA1 envía ACK.
2) UA1 envía re-INVITE para poner en espera.
3) Pero Asterisk estaba enviando a UA2 un re-INVITE con el nuevo SDP (y
supongo que a la vez se lo envía también a UA1).
4) Antes de que UA1 y UA2 envíen 200 a los re-INVITE y reciban ACK de Asterisk
resulta que UA1 envía re-INVITE para poner en espera.
5) Asterisk responde 491 a UA1. Esto sólo debe ocurrir si Asterisk *ya* había
enviado el re-INVITE a UA1 y UA1 no había contestado aún:
A UAS that receives an INVITE on a dialog while an INVITE it had sent
on that dialog is in progress MUST return a 491 (Request Pending)
response to the received INVITE.
Lo que no entiendo es esto:
> El caso es que como asterisk se encuentra tramitando el re-
> INVITE pues me contesta con una response 491 Request Pending a mi
> solicitud de poner la llamada en espera. Hasta ahí todo bien, yo le
> contesto a Asterisk con un ACK y una vez hecha la reconfiguración
¿Te refieres a una vez que UA1 ha enviado 200 al re-INVITE de Asterisk (nuevo
SDP) y recibido ACK de Asterisk?
> trato de poner la llamada en espera con un nuevo re-INVITE (el cual
> hace bien
¿A qué te refieres con que hace bien? ¿devuelve Asterisk 200 y pone la llamada
en espera?
> - sin embargo no da el primero como finalizado porque sigue
> reenviando la respuesta SIP 491).
O sea, hay retransmisiones de la respuesta 491 a pesar de que UA1 le envió un
correcto ACK, ¿cierto? (esto huele a bug cochino en el chan_sip).
> El problem está en que Asterisk no se da por satisfecho al responderle
> con un ACK y por lo tanto continúa retransmitiendome el Request
> Pending hasta que da por finalizada la llamada. Según el rfc3261 al
> recibir la respuesta request pending debería de iniciar un timer que
> determine cuándo debe volver a enviarse mi INVITE...lo he hecho
> enviándole tanto el mismo INVITE como uno nuevo, sin éxito, Asterisk
> seguía reenviandome el primer request pending y luego finalizaba la
> llamada.
> Sin embargo al cabo de unos 20 segundo se produce este aviso en la
> consola de Asterisk:
>
> Aug 21 11:21:06 WARNING9686: chan_sip.c:1967 retrans_pkt: Maximum
> retries exceeded on transmission
> 0dd43bb5a64eb5a2...@10.110.7.89 for seqno 5 (Critical
> Response) — See doc/sip-retransmit.txt.
> Aug 21 11:21:06 WARNING9686: chan_sip.c:1989 retrans_pkt: Hanging up
> call 0dd43bb5a64eb5a2...@10.110.7.89 - no reply to our
> critical packet (see doc/sip-retransmit.txt).
¿Puedes habilitar el sip debug en el CLI y ver qué dice Asterisk cuando recibe
el ACK que el envías con motivo del 491? ¿lo desecha? (es lo que parece). Si
es así es un pedazo bug de Asterisk.
> y se cuelga la llamada. También he intentado enviar un cancel del
> INVITE pero tampoco he obtenido ningún éxito ya que asterisk ya me
> había contestado con la respuesta 491 Request Pending.
Aunque el re-INVITE para poner en espera se haga bien, si Asterisk detecta que
una transacción no ha terminado correctamente (ha expirado el INVITE-491)
acaba el diálogo).
> ¿Alguien sabe qué es lo que estoy haciendo mal?
No creo que el fallo esté en tu lado.
> ¿Qué tengo que hacer
> para que Asterisk no me reenvie el Request Pending y luego de por
> finalizada la llamada?
Reportar el bug en el tracker de Asterisk y rezar para que Olle tenga algo de
tiempo :)
--
Iñaki Baz Castillo
<ib...@xtratelecom.es>
joaquindk
Más o menos creo q me has entendido bien, el flujo de mensajes es el
siguiente:
1) UA1 lanza el primer INVITE, Asterisk envía INVITE a UA2, recibe 200
de UA2
y le envía ACK, responde 200 a UA1 y UA1 envía ACK.
3) Antes de recibir el UA1 el re-INVITE de Asterisk, le envía un
INVITE a este con la petición de HOLD, a la cual Asterisk responde
con un 491 Request Pending. UA1 contesta con un ACK
4) UA1 recibe el re-INVITE de Asterisk con el nuevo SDP, contesta con
un 200 OK y recibe un ACK de asterisk
5) UA1 vuelve a intentar el re-INVITE para el hold - recibe un 200 OK
de asterisk y contesta con un ACK. ESTE hold se hace correctamente.
6) Asterisk continua reenviando el Request Pending hasta que opta por
finalizar la llamada - todos estos request pending son respondidos con
un ACK - sin embargo no tienen efecto.
> Lo que no entiendo es esto:
>
> > El caso es que como asterisk se encuentra tramitando el re-
> > INVITE pues me contesta con una response 491 Request Pending a mi
> > solicitud de poner la llamada en espera. Hasta ahí todo bien, yo le
> > contesto a Asterisk con un ACK y una vez hecha la reconfiguración
>
> ¿Te refieres a una vez que UA1 ha enviado 200 al re-INVITE de Asterisk
(nuevo
> SDP) y recibido ACK de Asterisk?
> > trato de poner la llamada en espera con un nuevo re-INVITE (el cual
> > hace bien
>
> ¿A qué te refieres con que hace bien? ¿devuelve Asterisk 200 y pone la
llamada
> en espera?
pone en espera correctamente, pero pasado un rato siguen llegando
los REQUEST PENDING y al final asterisk cuelga.
>
> > - sin embargo no da el primero como finalizado porque sigue
> > reenviando la respuesta SIP 491).
>
> O sea, hay retransmisiones de la respuesta 491 a pesar de que UA1 le envió
un
> correcto ACK, ¿cierto? (esto huele a bug cochino en el chan_sip).
> > El problem está en que Asterisk no se da por satisfecho al responderle
> > con un ACK y por lo tanto continúa retransmitiendome el Request
> > Pending hasta que da por finalizada la llamada. Según el rfc3261 al
> > recibir la respuesta request pending debería de iniciar un timer que
> > determine cuándo debe volver a enviarse mi INVITE...lo he hecho
> > enviándole tanto el mismo INVITE como uno nuevo, sin éxito, Asterisk
> > seguía reenviandome el primer request pending y luego finalizaba la
> > llamada.
> > Sin embargo al cabo de unos 20 segundo se produce este aviso en la
> > consola de Asterisk:
>
> > Aug 21 11:21:06 WARNING9686: chan_sip.c:1967 retrans_pkt: Maximum
> > retries exceeded on transmission
> > Aug 21 11:21:06 WARNING9686: chan_sip.c:1989 retrans_pkt: Hanging up
>
> ¿Puedes habilitar el sip debug en el CLI y ver qué dice Asterisk cuando
recibe
> el ACK que el envías con motivo del 491? ¿lo desecha? (es lo que parece). Si
> es así es un pedazo bug de Asterisk.
sea que supongo que no:
<--- Reliably Transmitting (no NAT) to 10.110.7.89:5070 --->
Via: SIP/2.0/UDP
From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
To: <sip:30...@10.110.7.20>;tag=as752bc23c
Call-ID: a336c0bebd6ee5557fdaca7cbad8d
<--- SIP read from 10.110.7.89:5070 --->
ACK sip:30...@10.110.7.20 SIP/2.0
Call-ID: a336c0bebd6ee555...@10.110.7.89
Max-Forwards: 70
From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
To: <sip:30...@10.110.7.20>;tag=as752bc23c
Via: SIP/2.0/UDP
10.110.7.89:5070;branch=z9hG4bK71b8d17d2dcd72ca4d30365f0632fbab
CSeq: 9 ACK
Content-Length: 0
Retransmitting #1 (no NAT) to 10.110.7.89:5070:
Via: SIP/2.0/UDP
From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
To: <sip:30...@10.110.7.20>;tag=as752bc23c
Call-ID: a336c0bebd6ee555...@10.110.7.89
CSeq: 9 INVITE
User-Agent: Asterisk PBX
<--- SIP read from 10.110.7.89:5070 --->
ACK sip:30...@10.110.7.20 SIP/2.0
Call-ID: a336c0bebd6ee555...@10.110.7.89
Max-Forwards: 70
From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
To: <sip:30...@10.110.7.20>;tag=as752bc23c
Via: SIP/2.0/UDP
10.110.7.89:5070;branch=z9hG4bK71b8d17d2dcd72ca4d30365f0632fbab
CSeq: 9 ACK
Content-Length: 0
Supported: replaces
Content-Length: 0
X-Asterisk-HangupCause: Normal
Muchas gracias!
Joaquín.
Iñaki Baz Castillo
> He habilitado el debug y asterisk no especifica si lo deshecha o no, o
> sea que supongo que no:
Pues yo creo que sí lo desecha (en el sentido en el que lo ignora) puesto que
lo recibe pero acto seguido envía una retransmisión del 491 (Retransmitting
#1 (no NAT) to 10.110.7.89:5070).
El ACK que envías es correcto así que tiene que ser un bug de Asterisk
(apuesto lo que sea).
> <--- SIP read from 10.110.7.89:5070 --->
> ACK sip:30...@10.110.7.20 SIP/2.0
> Call-ID: a336c0bebd6ee555...@10.110.7.89
> Max-Forwards: 70
> From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
> To: <sip:30...@10.110.7.20>;tag=as752bc23c
> Via: SIP/2.0/UDP
> 10.110.7.89:5070;branch=z9hG4bK71b8d17d2dcd72ca4d30365f0632fbab
> CSeq: 9 ACK
> Content-Length: 0
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Length: 0
> X-Asterisk-HangupCause: Normal
Por cierto, este ACK lo envía tu UA, ¿cómo es que tiene esa
cabecera "X-Asterisk-HangupCause: Normal"??
joaquindk
> > From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
> > To: <sip:30...@10.110.7.20>;tag=as752bc23c
> > Via: SIP/2.0/UDP
> > 10.110.7.89:5070;branch=z9hG4bK71b8d17d2dcd72ca4d30365f0632fbab
> > CSeq: 9 ACK
> > Content-Length: 0
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > Supported: replaces
> > Content-Length: 0
> > X-Asterisk-HangupCause: Normal
> Por cierto, este ACK lo envía tu UA, ¿cómo es que tiene esa
> cabecera "X-Asterisk-HangupCause: Normal"??
Call-ID: a336c0bebd6ee5557fdaca7cbad8d...@10.110.7.89
From: <sip:30...@10.110.7.20:5070>;tag=SIPTester
To: <sip:30...@10.110.7.20>;tag=as752bc23c
Via: SIP/2.0/UDP
10.110.7.89:5070;branch=z9hG4bK71b8d17d2dcd72ca4d30365f0632fbab
CSeq: 9 ACK
Content-Length: 0
estoy utilizando las librerías JAIN-SIP para el desarrollo del UA, las
cuales generan de forma automática el ACK al 491 Request Pending.
Fijándome en las trazas, dado que el ACK se trata de una petición he
visto que su parámetro branch en la via header varía con respecto a
aquel del la respuesta que lo origina. Sin embargo, las librerías JAIN-
SIP, en este caso, están utilizando el mismo valor para branch que el
que se emplea en la respuesta....voy a intentar generar de forma
manual el ACK a ver si tengo más suerte!
joaquindk
> estoy utilizando las librerías JAIN-SIP para el desarrollo del UA, las
> cuales generan de forma automática el ACK al 491 Request Pending.
> Fijándome en las trazas, dado que el ACK se trata de una petición he
> visto que su parámetro branch en la via header varía con respecto a
> aquel del la respuesta que lo origina. Sin embargo, las librerías JAIN-
> SIP, en este caso, están utilizando el mismo valor para branch que el
> que se emplea en la respuesta....voy a intentar generar de forma
> manual el ACK a ver si tengo más suerte!
Iñaki Baz Castillo
> He visto una cosa que podría explicar lo que está pasando. Resulta que
> estoy utilizando las librerías JAIN-SIP para el desarrollo del UA, las
> cuales generan de forma automática el ACK al 491 Request Pending.
> Fijándome en las trazas, dado que el ACK se trata de una petición he
> visto que su parámetro branch en la via header varía con respecto a
> aquel del la respuesta que lo origina. Sin embargo, las librerías JAIN-
> SIP, en este caso, están utilizando el mismo valor para branch que el
> que se emplea en la respuesta....voy a intentar generar de forma
> manual el ACK a ver si tengo más suerte!
Ojo, cuando se trata de un ACK para una respuesta afirmativa (2XX) el ACK es
una *nueva* transacción, y por lo tanto tiene un *nuevo* branch (distinto del
del INITE/2XX al que sigue).
Pero cuando el ACK es para confirmar la recepción de una respeusta negativa
(3XX - 6XX) entonces el ACK se considera parte de la transacción, es enviado
hop by hop por los proxies intermediarios y el branch del Via es el *mismo*
que en el INVITE/[3456]XX.
El ACK que envía tu cliente para el 491 es perfectamente correcto.
joaquindk
> Ojo, cuando se trata de un ACK para una respuesta afirmativa (2XX) el ACK es
> una *nueva* transacción, y por lo tanto tiene un *nuevo* branch (distinto del
> del INITE/2XX al que sigue).
>
> Pero cuando el ACK es para confirmar la recepción de una respeusta negativa
> (3XX - 6XX) entonces el ACK se considera parte de la transacción, es enviado
> hop by hop por los proxies intermediarios y el branch del Via es el *mismo*
> que en el INVITE/[3456]XX.
>
> El ACK que envía tu cliente para el 491 es perfectamente correcto.
>
> --
> Iñaki Baz Castillo
Cierto! me doy por vencido.
Joaquín.
Iñaki Baz Castillo
Reporta un detallado bug (en el que sobre todo se vean las trazas SIP y
el "sip debug" de Asterisk retransmitiendo el 491) y le damos calor ;)