ACK malformado
Raúl Alexis Betancor Santana
Estoy peleandome con la versi�n 2.0.0 de T38Modem y tengo la liguera
impresi�n de que tiene un bug en la pila SIP bastante gordo.
El escenario de pruebas es:
Server A: 192.168.1.40
- T38modem 2.0.0
- Hylafax 6
Proxy 1: 192.168.1.100
- Kamailio 3.1.4
- Sems 1.4.1 (SBC profile con B2BUA)
Olvidemos el resto, que funciona ok ...
Para abreviar, vamos a saltarnos toda la parte del INVITE -> TRYING
... etc, y vamos al punto en que llega el 200 OK desde el GW a trav�s
del proxy 1:
SIP/2.0 200 OK
Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4;did=c5d.9b292da5;vsf=aHZkZh1/Ohp6Mz5MeU90B1h4ZVFja3hsdxdRaw-->
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>
Record-Route: <sip:192.168.1.100;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>
CSeq: 2 INVITE
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bKaae5f49d-aac8-e011-9ded-0030489455f4;rport=5060
From: "root" <sip:kra...@192.168.1.100>;tag=7668f19d-aac8-e011-9ded-0030489455f4
Call-ID: e670f19d-aac8-e011-9ded-0030489455f4@sipapp02
To: <sip:9283...@192.168.1.100>;tag=37DEA9D8-4E4E1E3A00020392-B42EA700
Supported: timer
Session-Expires: 300;refresher=uas
Content-Type: application/sdp
Content-Length: 180
Contact: <sip:ngc...@192.168.1.100:5060>
v=0
o=msc415 0 0 IN IP4 192.168.1.100
s=sip call
c=IN IP4 192.168.1.100
t=0 0
m=audio 10034 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=nortpproxy:yes
Y este es el ACK cachondo que devuelve T38Modem:
ACK sip:9283...@192.168.1.100 SIP/2.0
Route: <sip:192.168.1.100;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>,<sip:127.0.0.1;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>,<sip:127.0.0.1:5062;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4;did=c5d.9b292da5;vsf=aHZkZh1/Ohp6Mz5MeU90B1h4ZVFja3hsdxdRaw-->
CSeq: 2 ACK
Via: SIP/2.0/UDP
192.168.1.40:5060;branch=z9hG4bK589985a1-aac8-e011-9ded-0030489455f4;rport
From: "root" <sip:kra...@192.168.1.100>;tag=7668f19d-aac8-e011-9ded-0030489455f4
Call-ID: e670f19d-aac8-e011-9ded-0030489455f4@sipapp02
To: <sip:9283...@192.168.1.100>;tag=37DEA9D8-4E4E1E3A00020392-B42EA700
Contact: <sip:kra...@192.168.1.40>
Proxy-Authorization: Digest username="krapula", realm="192.168.1.100", nonce="Tk4fZU5OHjlAm77GFgQr0gmNp7pm1N4R", uri="sip:9283...@192.168.1.100", algorithm=MD5, response="66987aa959e4f5b17b454e572fdd6d72"
Content-Length: 0
Max-Forwards: 70
Pregunta, �es correcta la forma de 'empaquetar' los Route en el ACK?
... lo pregunto, proque me parece rara de cojones, adem�s de que al
capturar la traza con sipspy y analizarla veo que al llegar el ACK
proxy, este hace un spiral y se lo env�a asimismo otra vez.
El problema gordo, viene en que seguido a este ACK, el T38modem env�a
un REINVITE para cambiar a modo t38 y desde el proxy, despu�s de hacer
otro spiral con el INVITE ... le termina contestando que 403 Domain
not served here.
�pistas?, �me fustigo con el RFC un rato?
Saúl Ibarra Corretgé
2011/8/19 Raúl Alexis Betancor Santana <ra...@dimension-virtual.com>:
> Buenas a todos ...
>
> Estoy peleandome con la versión 2.0.0 de T38Modem y tengo la liguera
> impresión de que tiene un bug en la pila SIP bastante gordo.
>
> El escenario de pruebas es:
>
>
> Server A: 192.168.1.40
> - T38modem 2.0.0
> - Hylafax 6
>
> Proxy 1: 192.168.1.100
> - Kamailio 3.1.4
> - Sems 1.4.1 (SBC profile con B2BUA)
>
>
> Olvidemos el resto, que funciona ok ...
>
> Para abreviar, vamos a saltarnos toda la parte del INVITE -> TRYING
> ... etc, y vamos al punto en que llega el 200 OK desde el GW a través
> Pregunta, żes correcta la forma de 'empaquetar' los Route en el ACK?
> ... lo pregunto, proque me parece rara de cojones, además de que al
> capturar la traza con sipspy y analizarla veo que al llegar el ACK
> proxy, este hace un spiral y se lo envía asimismo otra vez.
>
> El problema gordo, viene en que seguido a este ACK, el T38modem envía
> un REINVITE para cambiar a modo t38 y desde el proxy, después de hacer
> otro spiral con el INVITE ... le termina contestando que 403 Domain
> not served here.
>
> żpistas?, żme fustigo con el RFC un rato?
>
A primera vista lo que veo es que el ACK tiene el To del 200 OK como
RURI, no el Contact, por eso supongo que haga el loop.
Lo de los Route en una sola linea esta permitido, no recuerdo en que
parte del RFC lo dice...
Saludos,
--
/Saúl
http://saghul.net | http://sipdoc.net
Raúl Alexis Betancor Santana
> Aupa,
> A primera vista lo que veo es que el ACK tiene el To del 200 OK como
> RURI, no el Contact, por eso supongo que haga el loop.
Ergo se confirma mi sospecha de que est� malformado ... XDD , ahora
toca ver si es problema del c�digo de T38Modem o de la librer�a OPAL
que usa para la pila SIP y me temo que va a ser problema de OPAL ..
buff
> Lo de los Route en una sola linea esta permitido, no recuerdo en que
> parte del RFC lo dice...
Yep, me puse a repasar el RFC y lo encontr�, pero es que a veces
vienen bien un par de ojos m�s que te confirmen las sospechas ... que
uno acaba a veces de los call-flows hasta las narices .. XDD
Saludos
Iñaki Baz Castillo
<ra...@dimension-virtual.com> escribió:
>> A primera vista lo que veo es que el ACK tiene el To del 200 OK como
>> RURI, no el Contact, por eso supongo que haga el loop.
>
> toca ver si es problema del código de T38Modem o de la librería OPAL
> que usa para la pila SIP y me temo que va a ser problema de OPAL ..
> buff
El ACK a un 200 OK debe tener el Totag del 200 OK, eso está bien.
Lo que efectivamente está mal es que el cacharro está poniendo el RURI
del INVITE en el ACK al 200. El ACK a un 200 es un request
independiente de la transacción INVITE (de hecho el Via branch es
distinto), y el RURI de dicho ACK debe ser el Contact del 200.
Aún así, por pura casualidad resulta que el RURI original es:
y el URI del Contact del 200 es:
Es decir, sólo cambia el username. La IP es la misma y el puerto
tambień (ausencia de puerto en una SIP URI con IP como hostname es
5060 si el schema es "sip" como es el caso). Por lo tanto no entiendo
qué loop se produce. Aunque viendo el route set:
Route: <sip:192.168.1.100;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>,<sip:127.0.0.1;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>,<sip:127.0.0.1:5062;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4;did=c5d.9b292da5;vsf=aHZkZh1/Ohp6Mz5MeU90B1h4ZVFja3hsdxdRaw-->
- el request se entrega a 192.168.1.100 (proxy)
- proxy lo ruta a 127.0.0.1 (supongo que SEMS)
- SEMS lo ruta a 127.0.0.1:5062 (ya me pierdo...)
¿qué loop se produce exactamente?
>> Lo de los Route en una sola linea esta permitido, no recuerdo en que
>> parte del RFC lo dice...
>
> Yep, me puse a repasar el RFC y lo encontré, pero es que a veces
> vienen bien un par de ojos más que te confirmen las sospechas ... que
> uno acaba a veces de los call-flows hasta las narices .. XDD
--
Iñaki Baz Castillo
<i...@aliax.net>
Saúl Ibarra Corretgé
> El día 19 de agosto de 2011 13:21, Raúl Alexis Betancor Santana
> <ra...@dimension-virtual.com> escribió:
>>> A primera vista lo que veo es que el ACK tiene el To del 200 OK como
>>> RURI, no el Contact, por eso supongo que haga el loop.
>>
>> Ergo se confirma mi sospecha de que está malformado ... XDD , ahora
>> toca ver si es problema del código de T38Modem o de la librería OPAL
>> que usa para la pila SIP y me temo que va a ser problema de OPAL ..
>> buff
>
>
> El ACK a un 200 OK debe tener el Totag del 200 OK, eso está bien.
>
Quién ha dicho algo de tags? :-)
Raúl Alexis Betancor Santana
> El ACK a un 200 OK debe tener el Totag del 200 OK, eso est� bien.
>
> Lo que efectivamente est� mal es que el cacharro est� poniendo el RURI
> del INVITE en el ACK al 200. El ACK a un 200 es un request
> distinto), y el RURI de dicho ACK debe ser el Contact del 200.
>
> tambie?? (ausencia de puerto en una SIP URI con IP como hostname es
> 5060 si el schema es "sip" como es el caso). Por lo tanto no entiendo
>
> Route: <sip:192.168.1.100;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>,<sip:127.0.0.1;r2=on;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4>,<sip:127.0.0.1:5062;lr=on;ftag=7668f19d-aac8-e011-9ded-0030489455f4;did=c5d.9b292da5;vsf=aHZkZh1/Ohp6Mz5MeU90B1h4ZVFja3hsdxdRaw-->
>
> - el request se entrega a 192.168.1.100 (proxy)
> - proxy lo ruta a 127.0.0.1 (supongo que SEMS)
> - SEMS lo ruta a 127.0.0.1:5062 (ya me pierdo...)
>
>
Es una prueba sobre un NGCP 2.2 de sipwise ... configuran un LB proxy
en la IP p�blica, y luego el SEMS y el proxy registrar en una ip
privada y puertos diferentes.
UAC -> Proxy LB -> Proxy registrar
-> SEMS
Proxy LB = IP p�blica: 5060
127.0.0.1: 5060
Proxy Registrar = 127.0.0.1:5062
SEMS = 127.0.0.1:5080
Cuando se origina un invite desde el UAC ... hacen una picha de lio
del carajo ... pero se supone que funciona.
UAC -> Proxy LB -> Proxy registrar -> Proxy LB -> SEMS (B2BUA) ->
Proxy LB -> PSTN_GW
El loop se monta al recibir el proxy LB el ACK del UAC (t38modem en
este caso) al 200 Ok que le llega cuando se estable la comunicaci�n.
El proxy LB recib por la IP p�blica el ACK con la forma que ya mand�
en el otro correo, y en SU interfaz privada (127.0.0.1:5060), loopea
el ACK hacia 127.0.0.1:5060 y luego lo env�a al proxy registrar en el
127.0.0.1:5062.
Te voy a mandar las trazas por privado, a ver si le puedes echar un
ojo, porque ya no s� si realmente lo est� mandando mal o soy yo que
llevo ya demasiadas horas con esto .. XDD
Saludos
Iñaki Baz Castillo
<sag...@gmail.com> escribió:
>> El ACK a un 200 OK debe tener el Totag del 200 OK, eso está bien.
>>
>
> Quién ha dicho algo de tags? :-)
Mi otro yo, no me hagas ni caso, como si no he dicho nada.
Jon Bonilla
Raúl Alexis Betancor Santana <ra...@dimension-virtual.com> escribió:
> Cuando se origina un invite desde el UAC ... hacen una picha de lio
> del carajo ... pero se supone que funciona.
>
> UAC -> Proxy LB -> Proxy registrar -> Proxy LB -> SEMS (B2BUA) ->
> Proxy LB -> PSTN_GW
En realidad es UAC --> LB --> Proxy --> Sems --> LB --> PSTN
Raúl Alexis Betancor Santana
> El Fri, 19 Aug 2011 12:54:39 +0100
>
>
> > Cuando se origina un invite desde el UAC ... hacen una picha de lio
> > del carajo ... pero se supone que funciona.
> >
> > UAC -> Proxy LB -> Proxy registrar -> Proxy LB -> SEMS (B2BUA) ->
> > Proxy LB -> PSTN_GW
>
> En realidad es UAC --> LB --> Proxy --> Sems --> LB --> PSTN
Xasto, trastoqu� la parte de sems.
Ahora me sigue faltando averiguar donde demonios est� el problema,
porque el reinvite de T38modem sigue sin llegar a donde debe, de hecho
el ACK sigue haciendo 'cosas raras'
Saludos
Jon Bonilla
Raúl Alexis Betancor Santana <ra...@dimension-virtual.com> escribió:
> On Fri, Aug 19, 2011 at 04:16:31PM +0200, Jon Bonilla wrote:
> > El Fri, 19 Aug 2011 12:54:39 +0100
> > Raúl Alexis Betancor Santana <ra...@dimension-virtual.com> escribió:
> >
> >
> > > Cuando se origina un invite desde el UAC ... hacen una picha de lio
> > > del carajo ... pero se supone que funciona.
> > >
> > > UAC -> Proxy LB -> Proxy registrar -> Proxy LB -> SEMS (B2BUA) ->
> > > Proxy LB -> PSTN_GW
> >
> > En realidad es UAC --> LB --> Proxy --> Sems --> LB --> PSTN
>
> Xasto, trastoqué la parte de sems.
>
> Ahora me sigue faltando averiguar donde demonios está el problema,
> porque el reinvite de T38modem sigue sin llegar a donde debe, de hecho
> el ACK sigue haciendo 'cosas raras'
>
> Saludos
>
Qué dice el log del lb y de sems? Supongo que se quedará por ahí... Si no te
sale nada en el sems cámbiale el loglevel a 3
Aunque como te ha dicho Iñaki, ese ruri tiene mala pinta