[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Jan Janak]

Dragos Vingarzan wrote:
> Martin Hoffmann wrote:
>> Usually, I am much in favour of a multi-processing model as opposed to
>> multi-threading. Apache 1.3 was rock-solid because of this. However, the
>>
> I am for multi-threading, but this is not the point. I can live just
> well with multi-process, it's just that the whole thing was initially
> designed like "we know better, you do not need to fork new processes".

  Modules like sms and jabber create their own processes and these
  modules have been in the repository for years, you could use them as
  an example.

>> I can't really see this point but I don't know enough about all this
>> 3GPP stuff to seriously comment on it. Somewhere down the road dialogs
>> where mentioned. Sounds to me that the stuff is overly complex. Not that
>> I am in any way surprised given that this is Telco designed.
>>
> it's not about 3GPP though, but about doing more with SER. About
> dialogs, 3GPP recommends that you should check the Routes that the users
> are using inside dialogs, so that they won't go around the charging
> server for example. I don't think that this is such a exotic idea when
> you want to run a civilized network. 3GPP also recommends that you check
> that the Via headers were not changed so that the answer would go back
> on another path. This is also a good thing for a clean traffic.
>>
>>> SER is no longer "just a SIP proxy".
>> But it is just that. I don't really like all the attempts to make it
>> more than that (which is the main reason why I don't use SEMS). SER is a
>> proxy and a registrar. Everything more fancy shall be done somewhere
>> else.
>>
> Maybe you are right. That's OK with me, but then SER should stop
> claiming that flexibility and that huge list of things that it is good for.

  I don't quite get that. It certainly is flexible so why should we stop
  advertising it?

     Jan.