[OpenSER-Users-ES] Crear cabecera "Route" en vez de modificar URI cuando destino es "loose router".
Hola, en el RFC 3261 pone claramente que siempre que sea posible es preferible que el proxy SIP fuerce el desvío de un mensaje a otro servidor SIP insertando en el mensaje la cabecera "Route" (siempre claro, que sepa de antemano que el servidor destino es un "loose router").
En cambio, en todos los ejemplos que se ven , incluso en el curso del VON, siempre se proponía la modificación del URI (que implica el comportamiento de strict router en el servidor al que se envía el mensaje).
Es más, creo que nunca he visto un ejemplo de OpenSer en el que se inserte una cabecera "Route" para desviar el mensaje. En vez de ello, o se reescribe la URI ("$ru=XXXX", rewriteuri(XXX), seturi(XXX)) o se hace un "forward(XXX)".
Por ejemplo, para desviar la llamada a un Asterisk se suele hacer:
$rd = IP_asterisk; t_relay();
¿Cómo se haría eso mismo añadiendo una cabecera "route" en plan:?
add_route_hf("udp:IP_asterisk:5060"); t_relay;
¿Existe una función que haga eso? (yo al menos no la he encontrado).
Gracias.
PD: Igual es cosa de hacerlo en plan: insert_hf("Route: udp:IP_asterisk:5060\r\n"); pero me parece un poco... tristón.
El Sábado, 3 de Noviembre de 2007, Iñaki Baz Castillo escribió:
Perdón, quería decir:
insert_hf("Route: sip:IP_asterisk:5080;lr=on\r\n");
El Sábado, 3 de Noviembre de 2007, Iñaki Baz Castillo escribió:
Pues no sirve, resulta que si pongo ese "Route" el paquete se queda dando vueltas por OpenSer que además no lo reconoce como loop sino como espiral, así que acaba muriendo por "tamaño máximo".
Esta es la pinta que tiene el paquete en su iteración X:
U 2007/11/03 18:33:36.493976 82.14.0.110:5060 -> 82.14.0.110:5060 INVITE sip:route@sip.aliax.net SIP/2.0 Record-Route: sip:82.14.0.110;lr=on;ftag=ofxby;dialog-id=5fa.eecd7482 Route: sip:82.14.0.111:5080;lr=on Record-Route: sip:82.14.0.110;lr=on;ftag=ofxby;dialog-id=5fa.decd7482 Route: sip:82.14.0.111:5080;lr=on Record-Route: sip:82.14.0.110;lr=on;ftag=ofxby;dialog-id=5fa.cecd7482 Route: sip:82.14.0.111:5080;lr=on Record-Route: sip:82.14.0.110;lr=on;ftag=ofxby;dialog-id=5fa.becd7482 Route: sip:82.14.0.111:5080;lr=on Via: SIP/2.0/UDP 82.14.0.110;branch=z9hG4bKa369.f79c1404.0 Via: SIP/2.0/UDP 82.14.0.110;rport=5060;branch=z9hG4bKa369.e79c1404.0 Via: SIP/2.0/UDP 82.14.0.110;rport=5060;branch=z9hG4bKa369.d79c1404.0 Via: SIP/2.0/UDP 82.14.0.110;rport=5060;branch=z9hG4bKa369.c79c1404.0
Yo había rutado el paquete así:
insert_hf("Route: sip:82.14.0.111:5080;lr=on\r\n");
(allí hay un Asterisk escuchando).
Por otra parte me preocupa que esto no haya sido detectado como Loop. Según el RFC la construcción del parámetro branch en cada transacción se basa en un hash del from-tag, to-tag, call-id, uri, proxy-authenticacion, route. Todos esos parámetros son iguales en todos los paquetes que rebotan, y de hecho el branch es igual en todos: z9hG4bKa369.e79c1404.0 Si es el mismo branch... ¿por qué no se asume como Loop como indica el RFC?
Gracias por cualquier explicación.
Hola Iñaki,
¿En que parte pone esto?. En los puntos 16.4, 16.5 y 16.6 no lo entiendo así... además, es bastante habitual cargarse los "preloaded routes" si llegan a un proxy.
Saludos JesusR.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Domingo, 4 de Noviembre de 2007, Jesus Rodriguez escribió:
16.6 Request Forwarding
7. Determine Next-Hop Address, Port, and Transport
The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED; instead a Route header field should be used for that purpose as described above.
Si por ejemplo un usuario llama a un número PSTN entiendo que el proxy "MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI."
O sea, el proxy rutará la llamada al gateway SIP2PSTN.
Aunque ahora que lo leo no me queda tan claro, déjame que lo relea unas cuantas veces.
Gracias.
Hola,
Como te comenté, se suelen eliminar todas las "preloaded routes" que entran en un proxy... si te las tragas podrían pasarse toda tu política de routing (y de seguridad) por el forro...
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Tuesday 06 November 2007 11:34:22 Jesus Rodriguez escribió:
Ok, entonces ¿debería borrar las cabeceras "Route" que entran? (después claro de hacer loose_route().
Gracias.
Hola Iñaki,
Sólo se borra el Route cuando es una request inicial. Por ejemplo:
if ( !has_totag() || is_method("REGISTER") ) { # initial request -> preloaded ROUTE set ? if (loose_route()) { xlog("L_ERR", "Attempt to route with preloaded Route"); sl_send_reply("403","Preload Route denied"); } }
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
aunque desde las sombras, sigo el hilo jeje, esta me la apunto xD
2007/11/6, Iñaki Baz Castillo ibc@in.ilimit.es:
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra