[OpenSER-Users-ES] Y nos topamos con el NAT y t_replicate() ...

Raúl Alexis Betancor Santana rabs at dimension-virtual.com
Tue Jan 22 17:16:23 CET 2008


On Tue, Jan 22, 2008 at 04:47:07PM +0100, Iñaki Baz Castillo wrote:
> > La pregunta mágica es .. ¿Y como averiguar que tienen path? .. porque
> > he intentado con un $hdr(Path) y nanai, con un is_present_hf("Path") y
> > tampoco.
> 
> Eso nunca va a funcionar ya que la adicción o supresión de cabeceras se hacen 
> efectivas al abandonar el proxy, nunca durante el proceso del mensaje.

Ya, ya se que se produce el cambio cuando sale, pero creo que no me
has entendido ... pongo un ejemplo de traza:
Solo pongo el register de un UAC para abreviar.

UAC1           P1            P2       UAC2
REGISTER ->                    
         <- 401
REGISTER ->
         <- 200
			  add_path
			  t_replicate  ->
			                  save("location",0x03)
									        <- INVITE UAC1
										401  ->
										     <- INVITE UAC1
										100  ->
									 lookup()
								<- t_relay()
			 allow_trusted()
			 sl_reply("503")->
			 								  -> 503

El 503 se produce porque cuando el P2 hace el lookup(), encuentra al
UAC1 en su base de datos (gracias a replicate), pero cambia el RURI
ANTES de darse cuenta de que el UAC1 tiene en su AOR un Path como una
casa y cuando el INVITE llega a P1, el RURI ya no es válido.
Si cambio el RURI ($ru) después del lookup, la señalización continua
correcta, pero se me monta el bucle del RTP.

> > Estoy revisando el código de lookup() a ver donde demonios tiene el
> > tio en cuenta el Path, porque el módulo path.so solo registra un
> > callback hacia el módulo rr.
> 
> ¿Has leído esto?
>   Módulo "registrar":
>   1.1.1. PATH support
> http://www.openser.org/docs/modules/1.3.x/registrar.html#AEN41

Si y dice clarito ...

" A call to lookup(...) always uses the path header if found, and
inserts it as Route HF either in front of the first Route HF, or after
the last Via HF if no Route is present. It also sets the destination
uri to the first Path uri, thus overwriting the received-uri, because
NAT has to be handled at the outbound-proxy of the UAC (the first hop
after client's NAT)." 

En cristiano, que encontrará el Path y modificará el orden de los
Route acorde, pero también dice que modificará el RURI.

Umm ..., se me ocurre que si trato el INVITE que entra el P1 desde P2, 
como si fuese desde un GW PSTN (que tienen otro tratamiento diferente), 
puede que cuele ... voy a probar.

Saludos.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.




More information about the Users-es mailing list