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

[Dragos Vingarzan]

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. While some standard headers you can
traverse the values, on others you can't. And even on standard ones you
have to make sure each time that all the respective headers are parsed.
So no, iterating and comparing the names byte-by-byte of all headers is
not simple neither efficient for me... Maybe I am too lazy...
>
>   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.
>
>   I am just afraid that "architecture that takes into account.." means
>   that you want SER to be easy to use in common IMS scenarios, which
>   anything but mildly complicated.
>
If we look at the IMS case, each CSCF is specified in something like 20
pages. And those assume that you have a full RFC3261 proxy and then you
have a natural language routing script. This shouldn't be complicated to
translate then to SER's script, but it is...
>
>   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...
>
>   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?
>
>   I think there might be some confusion, you probably mean IMS when you
>   write SIP. I am not sure SER could play the "big role" in IMS
>   scenarios due to the fact that the specifications are simply too
>   complex and hard to implement.
>
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. And I don't
think that the specs are that hard. There is a 72 page RFC that explain
the concepts (RFC 4740, again).

-Dragos