Inaki,

Sorry missed the 'reply to all button'. I think what your saying makes sense, so simply enumerate each server:

i.e.

P1 - Set Flag 1 P2 - Set Flag 2 P3 - Set Flag 3

these flags will then be written to usrloc, and upon lookup read from usrloc.

In which case I can simply check this $bf psuedo variable for the specific server value, or even potentially do a lookup from a data source w/ avp_db_query and forward to associative proxy correctly by setting the destination uri.

Does this sound feasable? Thanks!

On Tue, Apr 21, 2009 at 1:59 PM, Iñaki Baz Castillo ibc@aliax.net wrote:

El Martes, 21 de Abril de 2009, Brandon Armstead escribió:

...

Inaki,

Please, mantain the thread in the maillist.

...

Thanks for the input -- that does look similar to what I'm looking to

do, however not 100%. From looking at the RFC it looks as if there is always a certain path being traversed, however in my case, its more of a "this is not the server that holds this user location socket binding,

lets

...

forward to the server that does".

So in essence:

UA1 can register to P1, P2, P3, and so on.....

However it does not register to P3 via the means of UA1 REGISTER -> P1 -> P2 -> P3 (REGISTRATION).

It simply registers directly to P1, or P2, or P3, etc....

In which case upon user lookup: lookup("location"), I want to be able to say "Hey I do not hold the socket for this registration, forward to

server

...

that does to do the actual lookup(location) and t_relay() to the UA.

Yes, it's a different scenario.

You could do some trick:

• When P1 receives a REGISTER it sets a bflag for it (bflag 1).
• When P2 receives a REGISTER it sets a bflag for it (bflag 2).
• When P3receives a REGISTER it sets a bflag for it (bflag 3).

When P1 receives a request and performs location for that AoR, it will also extract the bflags, so P1 checks if bflag 1 is on. If not and bflag 2 is on, then it routes (by setting $du => without changing the resolved RURI) the request to P2.

:)

-- Iñaki Baz Castillo ibc@aliax.net