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

[Greger V. Teigre]

I have always been a bit sceptic to adding lots of "B2BUA-like" 
functionality into SER. The complexity of administration and error 
correction increases and too much happens in one place.  That being 
said, there are stuff that people would like to do with "killing the 
performance" like a full B2BUA would do (is that true?? What about 
SEMS?)  So, I think we need to find a balance between pure SIP proxy 
functionality and non-RFC approved behavior.
Just to throw out an idea: What about distributing SER in two versions? 
One RFC-compliant, powerful, scalable SIP proxy, and one SER/SEMS bundle 
with different types of B2BUA functionality. 

Dragos. Did you evaluate using SEMS to accomplish parts of what you needed?
g-)

Dragos Vingarzan wrote:
> Jan Janak wrote:
>   
>>   I do feel Dragos' pain with IMS-like scenarios implemented in SER as I
>>   have been partially exposed to it, but I really think that a B2BUA
>>   like application server would do a better job there.
>>
>>   
>>     
> Maybe for an App Server. What I am trying to make out of it are the
> signaling routing functions, which are all SIP proxies with different jobs:
> - Proxy-CSCF - outbound proxy for UE, does NAT, security, asserts
> identities, enforces transaction, dialog and network routing policies
> - Interrogating-CSCF - almost stateless redirect proxy, just finds the
> registrar for a given user identity, also does some security ops on
> messages, like Topology Hidding
> - Serving-CSCF - registrar and service trigger by filtering and proxying
> traffic towards App Servers
>
> To me it seemed SER territory.  There is no B2B in there, just some mild
> UAC/UAS between the P and S-CSCF to synchronize those registrars. A
> B2BUA would just kill the performance. Although this performance should
> scale nicely, I wouldn't kill it with a bottleneck in this routing core.
>
> So I hope I am not misusing SER here.
>
> -Dragos
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.iptel.org/pipermail/serdev/attachments/20070129/8afe4911/attachment.htm