[Serdev] So who/what is SER for, anyway?

[Martin Hoffmann]

Dragos Vingarzan wrote:
> Jan Janak wrote:
> >
> >   Well, if you do not need the performance you do not have to extend the
> >   parser. Traversing the list of headers and comparing their names
> >   byte by byte is simple. If you still think this is not simple enough
> >   then maybe you could describe what the perfect API you are looking for
> >   should look like.
> >
> Well, e.g. only the order of the header values is important and those
> can appear grouped or not in a message.  So often you need to iterate
> through the headers of a certain type and find your values of interests.
> Many modules implement this search over and over again and some
> developers just forget about this.

I think this particular part has been taken care of with the selects
framework. I don't know whether these are easily available within the
modules as well, but with that framework available in the scripts, I
actually don't need to do any of the modules any more I had to write
earlier to cover for missing functionality. Others I would now design
differently, ie., at a lower level as to allow the script author to have
the final decision.

> >   If you want a SIP proxy then you do not need to deal with dialogs. I
> >   don't understand why everything should be put into the core.
> >
> sorry, I often say core instead of main functionality. I don't really
> care where it is, as long as I can rely on it.

But then, having a dialog module would be fine for you.

> >   There are other tools like asterisk, siproxd, and others that are
> >   easy to use for beginners.
> >
> is this a "go-away" shield at the entrance? exactly this bothers me...

Why? Specialisation is the secret behind the success of the human race.
Why write software that does everything? Rather, tailor your software to
a very specific purpose. In other words: Do one thing but do it right.

SER is a performance oriented SIP proxy. I think it is only fair to tell
people who want to use it for something else that they will most likely
spend quite some time and will be disappointed in the end.

This is what my "arrogant attitude" at the very beginning of this
discussion was about. In a way, it is not arrogant, it is saving some
people some frustration.

> >   This is a generic statement that may have different meaning to
> >   different people. I can argue that what you are proposing, i.e.
> >   turning SER into an application server with B2BUA capabilities (which
> >   is what you probably want) is not the right way to go. Such
> >   applications are available on the market.
> >
> no. I have never implied this. I just wanted to use SER's base as a
> foundation from some signaling routing nodes... isn't this a proxy?

You want to use it as IMS routing nodes. Apparently, these are not SIP
proxies. What a SIP proxy is and what it is allowed to do is very
clearly defined in The Standard. SER claims nothing more than to be one
(I think. Haven't read the blurbs in a long time).

> I never asked about a App Server platform. I am not interested into that
> area. The CSCFs deal only with routing signaling. Well, yes, they are a
> little smarter than simple SIP proxies, but not by much.

If it requires a B2BUA, it does things that in a pure SIP world belong
into a application server. Even though I think that writing a B2BUA on
top of SER is possible. Due to its design, you cannot reuse tm, though.

> And I don't
> think that the specs are that hard. There is a 72 page RFC that explain
> the concepts (RFC 4740, again).

If you consider that short, you really should stop reading ITU or 3GPP
recommendations.

Regards,
Martin