[Serdev] Path support

Tue Dec 5 17:32:53 UTC 2006

On Tue, 2006-12-05 at 16:54 +0100, Bogdan Pintea wrote:
> Hi Michal,
> 
> Michal Matyska wrote:
> > Using the snippet Vaclav showed, aligned to extract Path header from the
> > register request
> 
> How would "extraction" look like?
> Hope to haven't missed anything, but:
> - there is no Path core select support;

no need for specific support, textops selects are enough:
@hf_value.path or if you want be more strict
@hf_value.path[*].uri

> - the (experimental and only one, right?) path module lacks select support;
> - the 'select_param' non-terminal doesn't seem to allow addressing all
> Path header values - grouped into one or multiple headers -, or
> indexing, at all, for an anonymous header;
> - issuing the same select multiple times yields the same (first) result
> (, as expected :) ).

I do not follow, can you share the script snippet?

> In search of an answer, I also took a look over the "documentation" and
> run this statement against today's CVS HEAD:
> "$avp2 = @contact[1].uri;"

The contact select supports at the moment just the first contact, so the
construction like @contact[1] is not valid. I tried to dig through the
files, logs and docs (grep -r contact\[1\] :-) and nothing was found.
What "documentation" do you reffer to, so it could be updated?

Michal

> which ended up in:
> <<
>  0(25916) resolve_select: 'contact'
>  0(25916) resolve_select: [1]
>  0(25916) Unable to resolve select [1] at level 1
>  0(25916) BUG: route.c:492: Unable to resolve select
>  0(25916) select( 0(25916) contact, 0(25916) 1, 0(25916) uri, 0(25916) )
> ERROR: error -1 while trying to fix configuration
> >>.
> Am I doing anything wrong?
> (I actually wanted to see - rather than dig the code - what
> `@contact[0]' yields, as an attempt to address all contacts.)
> 
> BTW, the "BUG" might be a bug here, but it might also falsely alarm when
> user does a mistake: there is no bug if I write in my cfg `@foo', but a
> simple error.
> 
> 
>   Bogdan.
> 
> 
> PS. For sake of completeness:
> <<
> $ ./ser -V
> version: ser 0.10.99-dev62 (i386/linux)
> flags: STATS: Off, EXTRA_DEBUG, USE_IPV6, USE_TCP, DISABLE_NAGLE,
> USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC,
> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_DST_BLACKLIST
> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
> MAX_URI_SIZE 1024, BUF_SIZE 65535
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> @(#) $Id: main.c,v 1.224 2006/11/28 19:04:54 andrei Exp $
> main.c compiled on 15:06:19 Dec  5 2006 with gcc 4.1.1
> >>
> 
> 
> >  and adding it in the branch route as Route header
> > (using xxx_hf_value functions from textops module) one can easily build
> > full support for the Path.
> >
> > Michal
> >
> > On Tue, 2006-12-05 at 11:16 +0100, Vaclav Kubart wrote:
> >   
> >> Hi Klaus,
> >> OK, I didn't want to mystify somebody, I wanted only to show a way how
> >> to store things like Path...
> >>         Vaclav  
> >>
> >> On Tue, Dec 05, 2006 at 10:59:35AM +0100, Klaus Darilion wrote:
> >>     
> >>> Hi Vaclav!
> >>>
> >>> I tis not only storing the path header in the DB and loading it, but 
> >>> also the proper interpretation - changing the route set.
> >>>
> >>> regards
> >>> klaus
> >>>
> >>>
> >>> Vaclav Kubart wrote:
> >>>       
> >>>> Hi,
> >>>> I don't know about the patch, but for storing something with registered
> >>>> contact you can use "reg_avps" (AVPs stored with contact; you need only
> >>>> to set a flag to them before you call save and if you want to get them
> >>>> back, you can call "read_reg_avps"). So if you are able to translate
> >>>> Path into AVP(s) you can use it... It is not tested and not described
> >>>> but it can work... :-)
> >>>>
> >>>> Something like this was working some time ago:
> >>>>
> >>>> avpflags regavps;
> >>>>
> >>>> modparam("usrloc", "reg_avp_table", "contact_attrs");
> >>>> modparam("usrloc", "reg_avp_flag", "regavps")
> >>>>
> >>>> route {
> >>>> 	...
> >>>>
> >>>> 	if (method=="REGISTER") {
> >>>> 		$t.a = @msg["P-Avp"];
> >>>> 		$t.neco = "pokus";
> >>>> 		setavpflag("$t.a","regavps");
> >>>> 		setavpflag("$t.neco","regavps");
> >>>>
> >>>> 		save("location");
> >>>> 		break;
> >>>> 	}
> >>>> 	...
> >>>> }
> >>>>
> >>>> branch_route[1]
> >>>> {
> >>>> 	read_reg_avps("location", "$t.uid");
> >>>> 	xlog("L_ERR", "$t.a = %$t.a");
> >>>> 	...
> >>>> }
> >>>>
> >>>> If somebody will be interested, I can try to describe it better (and
> >>>> test a bit with Ottendorf)...
> >>>>
> >>>> 	Vaclav
> >>>>
> >>>> On Mon, Dec 04, 2006 at 09:25:05PM +0100, Greger V. Teigre wrote:
> >>>>         
> >>>>> Hi,
> >>>>> The path module in experimental was incomplete when Andreas Granig 
> >>>>> created a more complete patch. I believe the intention was to use Path 
> >>>>> headers together with usrloc-cl, thus enabling may registrars to save 
> >>>>> location to a common mysql db/cluster and easily route outgoing messages 
> >>>>> to the registrar/proxy being able to traverse the far-end NAT of a UA.
> >>>>>
> >>>>> What is the status of this patch in Ottendorf?  I believe the patch was 
> >>>>> posted to the bugtracker, but I cannot find it?!
> >>>>> g-)
> >>>>> _______________________________________________
> >>>>> Serdev mailing list
> >>>>> Serdev at lists.iptel.org
> >>>>> http://lists.iptel.org/mailman/listinfo/serdev
> >>>>>           
> >>>> _______________________________________________
> >>>> Serdev mailing list
> >>>> Serdev at lists.iptel.org
> >>>> http://lists.iptel.org/mailman/listinfo/serdev
> >>>>         
> >>> -- 
> >>> Klaus Darilion
> >>> nic.at
> >>>
> >>>       
> >> _______________________________________________
> >> Serdev mailing list
> >> Serdev at lists.iptel.org
> >> http://lists.iptel.org/mailman/listinfo/serdev
> >>     
> >
> > _______________________________________________
> > Serdev mailing list
> > Serdev at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
> >
> >   
> 
> 