[OpenSER-Devel] discussion: issues with local_route

Dan Pascu dan at ag-projects.com
Mon Jun 23 22:58:00 CEST 2008


On Monday 23 June 2008, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 06/20/08 13:49, Bogdan-Andrei Iancu wrote:
> > Hi Daniel,
> >
> > To summarize :
> >
> > 1) script flag - indeed there is an issue there and fortunately the
> > fix trivial - please open a bug report just not to forget about it
> >
> > 2) branch and branch_flags related function - these are not intended
> > to be used in local  route as it makes no sense. As, said, the core
> > does not allow any possibility to disable the core functions, so do
> > not use it. If you use it (against the description), you may loose
> > some info. But again, it is not a bug or missing, it is just about
> > using inappropriate functions in a route.
> >
> > 3) time PVs - as time as the PVs are bind to the message (by design),
> > it is normal to be refreshed when the processed message changes.
> >
> > I tried to addressed all your remarks that have a technical base. If
> > I missed some, please list them along arguments.
>
> I started to believe you don't understand exactly what happens. You now
> blame functions and functionalities that are there for ages, instead of
> allowing time for a proper analysis, design and integration of the
> local_route. You claimed that local route is a small patch with no
> impact on architecture or other code, perhaps it is no longer valid.

What exactly is broken? If I run openser with my 1.3 script will it work 
exactly the same or not? And if not is it a matter of a simple bug fix, 
or a complete redesign of the local_route?
So far I've seen only 1 issue that may affect the script flags and it's 
easy to fix.

> If you do not log branches, branch flags in acc or xlog, does not mean
> nobody else is doing. It is poor excuse to go with such motivation -
> the application must be coherent and consistent.

Yet, we have the same issues with reply_route and error_route. There are 
operations that make no sense there either. If you try them, they are 
either silently ignored or you get an error. What makes the local_route 
inconsistencies more relevant, while the other inconsistencies do not 
bother you?

You do remember that when first introduced, AVPs could not be accessed in 
the reply_route. It required another few releases until the ability to 
access them in the reply route was made possible. Following this logic, 
we should have never added the AVP support in the first place since it 
lacked this ability and even though some people did not use it, some 
others may have wanted to, but were unable.

> So, please, avoid argumentations with "inappropriate usage" or "not
> designed to be used there (but allowed)", it is just your opinion,
> besides that quality software and projects don't go out with such stuff
> in major releases.

But this is no singular case, and to speak in its defense I have to say 
that it's very new, so one cannot expect it to cover any use case, even 
those that were not imagined yet.

If it has to go down this path, then why don't we pick up on some 
functionality that is already in openser for 4+ generations and it has 
issues. TCP/TLS support is in there since 0.9.0 and today we still can't 
use it for end user devices. The consensus when this issue is raised, is 
that it is only supported for server connections, but I can also say that 
why should the end user device use case be labeled "inappropriate usage" 
when we target to release quality software?

So what do you say, if I connect 20000 SIP phone via TCP/TLS to the proxy 
will it be able to work properly as it does with UDP? If not, what should 
we do, should we remove TCP/TLS support because it is incomplete for this 
use case?

>
> To go further and complete the 1.4 release, the solution I see is to
> enclose local_route in defines in disable it by default. Who wants to
> use it, can recompile and reinstall from sources.

As I already said, I will support you in this direction if we can find any 
problems that break the existing proxy functionality and cannot be fixed 
easily. However if there are no show stoppers, only incomplete stuff, I 
have to disagree. Every new functionality was incomplete in the 
beginning, and required multiple releases until it reached maturity and 
sometimes even required design changes between those releases to allow it 
to be implemented in a more complete form. Nothing new with local_route.

-- 
Dan



More information about the Devel mailing list