[Serdev] Path support

[Greger V. Teigre]

Michal,
Yes, the new mechanisms are really powerful. For advanced users, who 
need full control for tweaking, this is excellent. However, there are 
many others who would probably end up reducing their RFC-compliance even 
further by trying to implement such complex (as in "coordinated changes 
in more than one message/type") functionalities.

What is reasonable to implement as a "feature package" with functions 
and parameters and what should be implemented using generic functionality? 
I think Path header support is an example of the first.
g-)

Michal Matyska wrote:
> Using the snippet Vaclav showed, aligned to extract Path header from the
> register request 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
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20061205/8ae1a730/attachment.html