[Serdev] SER as an extendable codebase/SIP stack - was: So who/what is SER for, anyway?

Greger V. Teigre greger at teigre.com
Mon Jan 29 21:13:51 UTC 2007



Dragos Vingarzan wrote:
>>> 4. Because the CSCFs are just standard IETF SIP Proxies, on which 3GPP
>>> recommends some usage patterns. it's not like 3GPP/IMS would reinvent
>>> SIP proxies. They are just usage patterns and if you would look at the
>>> RFC 4740, you would see the same architecture. If SER is a good SIP
>>> proxy, it should also be a good CSCF.
>>>   
>>>       
>> Yes, I see the arguments. I also see why you have had frustrations :-) 
>> I'm not sure if SER "should also be a good CSCF" by virtue of being a
>> good SIP proxy. Or maybe said differently: I think a more interesting
>> question from a SER development perspective is: Should SER have a
>> design/architecture that enables people to extend it with
>> functionality like for example CSCF? And where do we stop before a
>> good proxy has been turned into a bad "everything-for-all" ?
>>     
> I hope that you are not saying that SER should be intentionally against
> being CSCFs :)... because that would be too big of an effort to cripple
> SER ;-).
>   
Well, no, I'm just saying that there should be some criteria for what is 
natural to do in SER and what is not. Maybe CSCFs are outside, I dunno, 
I would guess not.

>>>>  * Would you use SER if you had to make the decision again?
>>>>
>>>>     
>>>>         
>>> Unfortunately, NO. Because at this point there are certain easy features
>>> that would take too much time to do them with SER than start over with a
>>> new architecture. What keeps me to SER now is just it's stability and
>>> the fact that a new base would be unstable for a long period of time
>>> (too long for our academical and research-only purposes).
>>>   
>>>       
>> Thanks for being honest :-)
>>     
> Well, half of my response is good and half is bad. Taking the good part
> - stability - I think that one is quite good.
>
> And I have also realized why Martin is upset on my wave of change
> requests: I was using 0.10.99 for a looong time now. For me it's old
> news. And I am quite satisfied with it. The only outstanding thing that
> I have might not be a bug. And having to fix one-two bugs every couple
> of months is not bad at all. So, sorry guys, but I was kind of jumping
> forwards and wanting a 0.11.99 :-P in the short term.
>   
Hehe, good clarification...
>>> more internal APIs, better&transparent standard compliance, extend the
>>> core with the most used ops in the modules
>>>   
>>>       
>> I get the first one, the two last I'm a bit uncertain, but I'll pick
>> it up in later posts and threads...\
>>     
> standard compliance - would be nice to have some sanity checks on send
> or something like that, if not more enforcement
>   
I see, like the sanity checks in the what's-it-called module?
> extensions to the core - they don't really have to be in the core. just
> that I want to rely on something. I am crying here for a bigger and
> stronger base.
>   
Ok, what would really help here would be if you could create a list of 
exactly the changes that should be done and based on the discussion so 
far, comment on the differing perspectives. You could add a new 
Discussion page on iptel.org, a bit similar to the scalability/failover 
page I created:  Header, Description, Pros, Cons.
1. That would keep a summary of this VEEEERY long thread in one place
2. Specific suggestion would get a separate section where people can add 
their pros and cons
3. We can debate out of a precise description instead of feelings of 
what a feature is
4. Hopefully, SER will improve for ALL parties
>> I hope Martin has by now showed you that somebody would actually want
>> that and why ?!
>> g-)
>>     
> well, he did. But I hope that SER's meaning is NOT to make stupid and
> broken SIP clients barely usable. Because this flexibility is also very
> dangerous and often SER+cfg is misbehaving after so many tweaking.
>   
Yes, it's unfortunately a big problem when vendors get away with bad 
implementations.  Removing ability to tweak in SER doesn't force them 
though...
> And again, there is a huge difference between me and Martin: it looks
> like I am already bored with Ottendorf, while others just seen it's
> power. I can leave with minor bugs, although the current version did not
> gave me trouble at all. Sorry, I'll come back in 6 months :-).
>   
:-D No please, participate in the discussion of what Ipteldorf should be!
g-)
> -Dragos
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/49a4f287/attachment.html


More information about the Serdev mailing list