because i didn't think of it?
:-)
cheers, and thanx
Bogdan-Andrei Iancu wrote:
Kanakatti Mahesh Subramanya wrote:
I totally agree.
Personally, I've been ripping out large chunks of my config file, and
replacing it with varioud avpops based stuff - it may be *slightly*
more convoluted, but it is completely database configurable, and
hence easier to maintain
re: rr, its actually neither. Its a static, which i'm using to
identify NAT'ed clients to account for re-INVITEs
why don't you use the append_rr_param() function to added the NAT
identifier to the RR hdr? do a normal record_route() and if nat is
detected, add the param
regards,
bogdan
>
> cheers
>
> Bogdan-Andrei Iancu wrote:
>
>> Hi Kanakatti,
>>
>> I'm for m4'ing (for the moment) for two reasons:
>> 1) since we can do it with m4, I prefer to use the cycles for
>> something still missing;
>> 2) using dynamic parameters (like via AVPs) reduce the
>> performance - time to look for the AVP and most critical the
>> impossibility of calling fixup functions at startup (which will
>> force to fix params at runtime, for each processing).
>>
>> regarding the record_route_preset() - do you use dynamic parameters
>> or dynamic rr URI?
>>
>> regards,
>> bogdan
>
>